Skip to main content

260731-Claude et SASNEXTE sur le PC Elio+Jux

WireGuard sasnexte sur le PC Elio+Jux — diagnostic et résolution

Date : 2026-07-31 | Machine : PC Windows eliob | NAS cible : sasnexte (82.66.244.248) Statut : RÉSOLU — tunnel activé, lecteur S: mappé sur \\10.0.0.2\NEXTE

Question initiale

WireGuard a été monté sur ce PC et sur le NAS sasnexte, mais le disque du NAS n'apparaissait pas comme lecteur dans l'explorateur de fichiers Windows. Pourquoi ?

Réponse courte

Deux causes cumulées :

  1. Le tunnel n'était pas activé sur le PC : la config vps_maisonpc_sasnexte était importée dans l'application WireGuard, mais jamais activée (aucun service WireGuardTunnel$*, aucun adaptateur réseau, wg show vide).
  2. Un lecteur réseau ne se crée jamais tout seul : la découverte réseau Windows (broadcast/mDNS/WS-Discovery) ne traverse pas un tunnel de couche 3 — le NAS n'apparaîtra jamais spontanément dans « Réseau ». Il faut mapper manuellement une lettre avec net use.

Topologie du tunnel vps_maisonpc_sasnexte

Réseau 10.0.0.0/24, hub-and-spoke avec le VPS Jux comme serveur (wg0, port UDP 51820) :

IP Machine État (2026-07-31)
10.0.0.1 VPS Jux (51.77.141.54) — hub Serveur, forwarding OK (ACCEPT in wg0 dans FORWARD)
10.0.0.2 NAS sasnexte (endpoint 82.66.244.248) Connecté, handshake actif, 485 Gio transférés
10.0.0.3 PC Windows eliob Connecté (après activation du tunnel)
10.0.0.4 PC maison (peer MkzKqDe…) Jamais connecté (pas d'endpoint)

Clé publique serveur VPS : zbsY/bl4fHU1eR29PjTruK0Nrmp/BQORSlBGSh3Nkyo=

Diagnostic détaillé

Côté PC (avant activation)

  • Application WireGuard installée, service WireGuardManager Running
  • Config importée (dossier C:\Program Files\WireGuard\Data\Configurations présent, chiffré DPAPI, admin uniquement) mais tunnel inactif
  • Aucun .conf en clair dans le profil utilisateur — pour l'exporter : app WireGuard en admin → « Exporter les tunnels »

Après activation du tunnel

  • Adaptateur vps_maisonpc_sasnexte Up, IP 10.0.0.3/24
  • wg.exe show échoue en non-admin (Permission denied) — normal, utiliser Get-NetAdapter / Get-NetIPAddress pour vérifier sans élévation
  • Piège ICMP : le NAS ne répond PAS au ping (pare-feu Synology) alors que le tunnel fonctionne. Ne pas diagnostiquer au ping — tester en TCP : Test-NetConnection 10.0.0.2 -Port 445
  • Ports NAS via tunnel : 445/139 (SMB) OK, 22 (SSH) OK, 5000/5001 (DSM) bloqués

SSH sasnexte depuis l'extérieur

Le SSH sas_nexte@82.66.244.248 (IP publique) refusait le mot de passe le 2026-07-31 alors que le même mot de passe fonctionne en SMB via le tunnel → le mot de passe est bon, c'est le SSH public qui est filtré (fail2ban/whitelist). Passer par le tunnel : ssh sas_nexte@10.0.0.2 (port 22 ouvert).

Résolution appliquée (2026-07-31)

  1. Tunnel activé dans l'app WireGuard (fait par Julien) → handshake OK avec le VPS
  2. Identifiants SMB enregistrés dans le gestionnaire d'identification Windows : 
    cmdkey /add:10.0.0.2 /user:sas_nexte /pass:"xAPIJU5108§"
  3. Lecteur mappé : 
    net use S: \\10.0.0.2\NEXTE /persistent:yes
  4. Vérifié : S: liste bien le contenu du partage NEXTE

Important : le lecteur S: ne fonctionne que si le tunnel WireGuard est actif. Après un reboot, le tunnel se réactive automatiquement (service WireGuardTunnel$vps_maisonpc_sasnexte en démarrage auto) et Windows reconnecte S: grâce à /persistent:yes + identifiants cmdkey.

Partages SMB disponibles sur \10.0.0.2

ActiveBackupforBusiness, audiobooks, chat, home (dossier perso SAS_NEXTE), homes, Iso VM, music, NetBackup, NEXTE (mappé sur S:), Public_s, RAW, Ressources_NEXTE, retro, web, web_packages

Pour mapper un partage supplémentaire (les identifiants sont déjà enregistrés) :

net use R: \\10.0.0.2\Ressources_NEXTE /persistent:yes

Points ouverts

  • Finaliser la config Ubuntu : exporter le .conf depuis l'app WireGuard Windows (admin → Exporter les tunnels) — le peer 10.0.0.4 libre pourrait aussi servir pour Ubuntu
  • Identifier le peer 10.0.0.4 (MkzKqDeVoIX9R9oMlCK7c76e3c3p/DJe/ryd0eqEV20=) : prévu pour le PC maison, jamais connecté

Restauration du 2026-08-27 — après la réinstallation de Windows

Statut : RÉSOLU. Tunnel rétabli, S: remonté. Le poste s'appelle désormais julie — c'est la même machine que « PC Elio+Jux », réinstallée le 2026-08-08 (voir CLAUDE.md).

Ce qui s'était passé

La réinstallation de Windows a emporté WireGuard et, avec lui, la clé privée du peer 10.0.0.3. Elle vivait dans C:\Program Files\WireGuard\Data\Configurations, chiffrée par DPAPI — irrécupérable, exactement comme l'identité Syncthing PC-Elio+Jux perdue au même moment.

Le diagnostic se lit d'une seule commande sur le VPS :

peer: cMDglLZZrrZUL4QdtB5nHQFe0U5fdzXzaWnmihw1b0o=
  endpoint: 83.195.45.93:63884
  allowed ips: 10.0.0.3/32
  latest handshake: 19 days, 23 hours, 41 minutes ago

19 jours et 23 heures avant le 27/08 à 21 h ramènent au 7 août en soirée, soit la veille de la réinstallation (8 août à 12:21). Le NAS, lui, faisait des handshakes toutes les quelques secondes : côté VPS et côté NAS, rien n'était cassé. Seul le poste avait disparu.

Recherche préalable infructueuse, mais qui valait la peine : aucun .conf exporté nulle part sur D:, ni dans l'arbre Syncthing, ni dans le profil. Le point ouvert « exporter le .conf pour Ubuntu » de juillet n'avait jamais été fait — sans quoi l'identité aurait pu être restaurée telle quelle.

Décision : réutiliser l'adresse 10.0.0.3, pas le peer libre 10.0.0.4

Le peer 10.0.0.4 était disponible, mais changer d'adresse aurait invalidé la documentation et, surtout, aurait risqué de buter sur d'éventuelles règles du pare-feu Synology référençant 10.0.0.3. On garde donc l'adresse et on ne remplace que la clé publique — le NAS n'a pas été touché.

Nouvelle identité du poste
Clé publique (nouvelle) UfqCwYB3T/XFl9qbpFR/8YSibq3Yta83fB9D2GAiW2A=
Clé publique (ancienne, morte) cMDglLZZrrZUL4QdtB5nHQFe0U5fdzXzaWnmihw1b0o=
Adresse 10.0.0.3/24, inchangée
Fichier client D:\WireGuard\vps_maisonpc_sasnexte.conf — hors de l'arbre Syncthing, une clé privée n'a rien à faire sur les 7 appareils du maillage

Paire générée par une implémentation X25519 en Python pur (aucune dépendance à installer), validée au préalable contre le vecteur de test de la RFC 7748 § 6.1 avant d'être utilisée.

Configuration cliente :

[Interface]
PrivateKey = <clé privée>
Address = 10.0.0.3/24

[Peer]
PublicKey = zbsY/bl4fHU1eR29PjTruK0Nrmp/BQORSlBGSh3Nkyo=
Endpoint = 51.77.141.54:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

AllowedIPs = 10.0.0.0/24 et non 0.0.0.0/0 : seul le trafic du VPN passe par le tunnel, la navigation ordinaire n'est pas détournée par le VPS. PersistentKeepalive = 25 maintient l'association NAT de la Livebox.

Côté VPS

Sauvegarde ‌/etc/wireguard/wg0.conf.bak-260827, remplacement de la clé publique du peer 10.0.0.3 et suppression de son Endpoint périmé, puis application sans redémarrer l'interface :

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg syncconf plutôt que wg-quick down/up : c'est le point important. Un redémarrage de l'interface aurait coupé le peer du NAS et remis ses compteurs à zéro. Après syncconf, le NAS a conservé son handshake et ses 962,99 Gio de compteur, sans la moindre interruption.

Vérifié au passage : -A FORWARD -i wg0 -j ACCEPT bien présent (posé par le PostUp), ip_forward = 1, 51820/udp ouvert dans ufw.

Côté poste

winget install --id WireGuard.WireGuard -e
& "C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice "D:\WireGuard\vps_maisonpc_sasnexte.conf"
cmdkey /add:10.0.0.2 /user:sas_nexte /pass:"xAPIJU5108§"
net use S: \\10.0.0.2\NEXTE /persistent:yes

/installtunnelservice évite entièrement l'interface graphique : il crée le service WireGuardTunnel$vps_maisonpc_sasnexte, le met en démarrage automatique et l'active dans la foulée. Le nom du tunnel est celui du fichier — d'où le choix de conserver vps_maisonpc_sasnexte.

⚠ Tout cela doit être tapé par Julien dans sa propre console, jamais depuis Claude Code. Le piège MSIX (page 282) ne concerne pas que les installeurs : cmdkey écrit dans %APPDATA%\Microsoft\Credentials et net use /persistent dans HKCU\Network, deux emplacements virtualisés par le conteneur. Lancées depuis une session Claude, ces commandes auraient annoncé un succès sans rien créer pour l'utilisateur.

Vérifié en direct le 2026-08-27 : une fois S: monté depuis la console de Julien, Test-Path S:\ répond False depuis la session Claude Code. Le cloisonnement joue aussi sur les lettres de lecteur — c'est un cas de plus à ajouter à la liste de la page 282.

Vérification finale

Contrôle Résultat
Test-NetConnection 10.0.0.2 -Port 445 True
net use S: « La commande s'est terminée correctement »
wg show sur le VPS — peer 10.0.0.3 endpoint 83.195.45.93:60519, handshake 36 s, 10,47 Kio reçus / 2,76 Kio envoyés
wg show sur le VPS — peer 10.0.0.2 (NAS) intact, handshake 30 s, 962,99 Gio — non perturbé

Le rappel de juillet reste valable : ne pas diagnostiquer au ping, le NAS ignore l'ICMP même tunnel actif. Test-NetConnection 10.0.0.2 -Port 445 est le seul témoin fiable.

Point ouvert, reformulé

Le peer 10.0.0.4 (MkzKqDe…) est toujours libre et n'a jamais servi. Pour raccorder la session Ubuntu, lui générer sa propre paire de clés — ne pas recopier le .conf du poste Windows, une clé privée ne se partage pas entre deux machines.

Piege du 2026-08-27 — un lecteur mappe en console administrateur reste invisible de l'explorateur

Apres la restauration du tunnel, S: n'apparaissait nulle part dans l'explorateur, et le premier reflexe (« le VPN ne marche pas ») etait faux : le service tournait, le VPS enregistrait des handshakes et du trafic.

Cause : Windows attribue deux jetons au compte administrateur — un filtre (normal) et un complet (eleve) — et les lecteurs reseau ne traversent pas cette frontiere. Les commandes d'installation (winget, /installtunnelservice) exigeant l'elevation, tout avait ete tape dans la meme console admin : net use avait donc cree S: pour le seul jeton eleve. L'explorateur, qui tourne en jeton normal, ne pouvait pas le voir.

Symptomes trompeurs :

    net use S: ... rejoue dans la console admin renvoie erreur systeme 85, « Nom de peripherique local deja utilise » — ce qui laisse croire que le lecteur existe bien le meme net use S: /delete en session normale repond « La connexion reseau est introuvable » — preuve que le lecteur n'y a jamais existe

    Correctif : rejouer le mappage dans une console non elevee (Win+R → powershell ; l'invite doit afficher C:\Users\julie et non C:\WINDOWS\system32).

    [Security.Principal.WindowsPrincipal]::new([Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole('Administrators')   # doit repondre False
net use S: \10.0.0.2\NEXTE /persistent:yes

    Les identifiants poses par cmdkey sont, eux, communs aux deux jetons (stockes par utilisateur) : inutile de les refaire.

    Alternative permanente, si le cloisonnement gene : poser EnableLinkedConnections a 1, ce qui fait partager les lecteurs entre les deux jetons. Necessite un redemarrage.

    New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name EnableLinkedConnections -PropertyType DWord -Value 1 -Force

    Second point de confusion, sans gravite : WireGuard n'affiche ni fenetre ni icone dans la zone de notification. C'est la consequence directe de /installtunnelservice, qui installe le tunnel comme service Windows — precisement ce qui garantit qu'il remonte au demarrage sans intervention. Pour le voir, lancer WireGuard depuis le menu Demarrer : le tunnel y figure, actif, avec ses compteurs.

    Regle a retenir : ne jamais diagnostiquer un tunnel a l'absence d'un lecteur dans l'explorateur. Les deux temoins fiables sont Test-NetConnection 10.0.0.2 -Port 445 cote poste, et sudo wg show cote VPS.

    Back to top