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) :

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é