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 : 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). 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) Tunnel activé dans l'app WireGuard (fait par Julien) → handshake OK avec le VPS Identifiants SMB enregistrés dans le gestionnaire d'identification Windows : cmdkey /add:10.0.0.2 /user:sas_nexte /pass:"xAPIJU5108§" Lecteur mappé : net use S: \\10.0.0.2\NEXTE /persistent:yes 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 = 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.