Repository navigation
Guide WireGuard Acces Distant
Fichier : Guide-WireGuard-Acces-Distant.md · Dossier : wiki (racine) Branche : master (wiki) · Auteur : hprzeta · MAJ : 2026-09-05
🧭 Rôle. Guide de référence pour joindre le cluster à distance via WireGuard, du concept (débutant) au dépannage fin (expert). Écrit après la session du 05/09/2026 où l'accès distant semblait « cassé » alors que rien ne l'était : le blocage venait d'un VPN tiers (Proton VPN) qui interceptait l'IPv6.
⚠️ Page publique : aucun secret ici. Les valeurs réelles (hostname DuckDNS, IPv6 de PC4, clés, token) sont remplacées par des placeholders<...>.
- Accès distant au cluster ⇒ Proton VPN OFF. Proton mange l'IPv6, et sans IPv6 le tunnel ne monte pas.
-
À la maison : accès direct
192.168.1.x, pas de tunnel, Proton peut rester ON. - Cluster injoignable ? Diagnostic dans l'ordre : IPv6 → VPN tiers → endpoint → tunnel (voir §4).
Ton cluster est à la maison. Quand tu es ailleurs, ton portable doit y arriver par un chemin. Ce chemin ressemble à ça :
TON PORTABLE HOTSPOT TUNNEL wg0 BASTION PC4 CLUSTER
(PC1 zeta-lab) (téléphone) (WireGuard) (la "porte") (PC1..PC4)
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐
│ │──────────│ donne │──────│ chiffré │────────│ seule │───────│ tes │
│ │ │ l'IPv6 │ │ bout à │ │ entrée │ │ nœuds │
│ │ │ │ │ bout │ │ du LAN │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └────────┘
Le chemin a une seule condition obligatoire : le réseau où tu es doit te fournir une adresse IPv6. Pourquoi ? Parce que la box SFR de la maison est derrière un CGNAT : elle n'a pas d'adresse IPv4 publique utilisable. La seule porte d'entrée depuis l'extérieur, c'est l'IPv6 de PC4.
Pas d'IPv6 sur le réseau → pas de chemin → cluster INJOIGNABLE.
IPv6 présente → tunnel monte → cluster ACCESSIBLE.
« À 16h ça marchait, ce soir non → donc quelque chose a cassé. »
FAUX. À 16h tu étais à la maison (accès direct, pas de tunnel, pas besoin d'IPv6). Le soir tu es en déplacement (tunnel obligatoire, IPv6 obligatoire). Le comportement change parce que le lieu change, pas parce que quelque chose s'est cassé.
L'IPv6 semblait absente (ip -6 addr ne montrait que du fe80:: lien-local). On a
soupçonné l'opérateur mobile. Faux. Le vrai coupable était Proton VPN, actif dans
Firefox/système :
SANS Proton : portable ──(IPv6 OK)──> hotspot ──> tunnel ──> PC4 ──> cluster ✅
AVEC Proton : portable ──> [PROTON VPN capte tout] ──✗── IPv6 bloquée
│
└─> le tunnel cluster ne peut plus sortir ❌
Un VPN commercial capte toute ta connexion. Deux effets :
- Blocage IPv6 — Proton désactive souvent l'IPv6 exprès (anti-fuite). Ton portable croit ne plus avoir d'IPv6 alors que le hotspot en donnait.
- Route par défaut — même IPv6 rétablie, tout part dans le tunnel Proton, donc le paquet WireGuard vers PC4 part au mauvais endroit.
# Proton ACTIF :
ip -6 addr show | grep -v fe80 # → rien (que du lien-local)
ping6 -c2 2001:4860:4860::8888 # → "réseau inaccessible"
# Proton COUPÉ (le SEUL changement) :
ip -6 addr show | grep -v fe80 # → 2a02:...:.../64 scope global ← IPv6 REVENUE
ping6 -c2 2001:4860:4860::8888 # → 0% packet loss
sudo wg-quick up wg0
ping -c2 [WG_PC4] # → 0% loss, ~58 ms, ttl=255 ← PC4 JOINT ✅Conclusion : le hotspot donnait l'IPv6 depuis le début ; Proton la mangeait.
ping [WG_PC4] (l'IP interne WireGuard de PC4) est le seul test fiable :
- PC4 ne répond jamais à un
ping6direct (echoreq bloqué danspf). - Un
ping6vers Google teste la sortie IPv6, pas le tunnel. -
wg showmontre l'état, mais seul un ping via[WG_PC4]prouve le handshake réel.
fe80::.../64 → lien-local, présent TOUJOURS, ne sert à RIEN pour sortir.
2a02:...:.../64 → GLOBALE, la seule qui permet de joindre PC4.
D'où le filtre correct : ip -6 addr show scope global (ou | grep -v fe80). Confondre
les deux = tourner en rond (l'erreur de la soirée).
| Piste | Faisabilité | Verdict |
|---|---|---|
| Split tunneling Proton (exclure WireGuard/PC4 du tunnel) | possible, mais support Linux limité/fragile | à tester à la maison seulement |
| Désactiver le blocage IPv6 dans Proton | parfois dispo, insuffisant seul | complément, pas solution |
| Ordre de montage (tunnel avant/après Proton) | tâtonnement | non fiable |
Reco : Proton OFF quand on veut le cluster. Simple, sûr, immédiat. Le split tunneling mal réglé peut créer des fuites (trafic « anonyme » qui sort en clair) — contraire au but de Proton.
Le « spam » de notifications (tunnel MORT → réparation → échec) venait du script qui
tentait de réparer alors qu'il n'y avait pas d'IPv6. Le v2 ajoute une garde : en
déplacement, s'il n'y a aucune IPv6 globale, le script se tait (ni wg-quick, ni
notify-send, juste une ligne de log). Dès que l'IPv6 revient (Proton coupé), il reprend
le comportement normal du 30/08.
# garde ajoutée (branche DÉPLACEMENT), avant toute action :
a_ipv6_globale() { ip -6 addr show scope global 2>/dev/null | grep -q inet6; }
if ! a_ipv6_globale; then
echo "$(date '+%F %T') | (silencieux) pas d'IPv6 globale — cycle ignoré" >> "$LOG"
exit 0
fiBackups : wg_auto.sh.bak-20260905 (état 30/08) et wg_auto.sh.bak-20260905-avant-v2.
Commité le 05/09/2026 (dépôt code, branche Riemann_Lab_C).
Cluster injoignable à distance ?
│
├─ 1. IPv6 présente ?
│ ip -6 addr show | grep -v fe80 (une GLOBALE 2a02:..., pas juste fe80::)
│ ping6 -c2 2001:4860:4860::8888
│ └─ KO → 1a. UN VPN TIERS EST-IL ACTIF ? (Proton VPN, autre)
│ → couper le VPN, retester. ← CAUSE N°1 (05/09)
│ → sinon : réseau sans IPv6 (opérateur/cellule) → réessayer ailleurs/plus tard.
│
├─ 2. Endpoint OK ?
│ dig +short AAAA <hostname>.duckdns.org (compare à l'IPv6 connue de PC4)
│ └─ AAAA périmée → chantier rotation DuckDNS (côté PC4).
│
└─ 3. Tunnel vivant ?
sudo wg show (handshake récent ?)
sudo wg-quick up wg0
ping -c2 [WG_PC4] ← SEUL test valide (0% perte attendu)
Règle d'or diagnostic : dig AAAA OK + ip -6 KO = presque toujours un VPN
tiers ou un réseau sans IPv6 — pas un problème de clé/config/PC4.
| Action | Commande |
|---|---|
| Voir l'IPv6 globale | ip -6 addr show | grep -v fe80 |
| Tester la sortie IPv6 | ping6 -c2 2001:4860:4860::8888 |
| Résoudre l'endpoint | dig +short AAAA <hostname>.duckdns.org |
| État du tunnel | sudo wg show |
| Monter le tunnel | sudo wg-quick up wg0 |
| Couper le tunnel | sudo wg-quick down wg0 |
| Test réel du tunnel | ping -c2 [WG_PC4] |
| Lancer session/monitoring | bash scripts/zeta_tmux.sh |
À la maison : rien à monter, accès direct 192.168.1.x.
Les alias zeta-* marchent à l'identique à la maison et à distance. Chaque nœud est testé : si son
port 22 répond en direct, connexion directe ; sinon ProxyJump par le bastion. Le bastion lui-même
passe par l'adresse du tunnel ([WG_PC4]) quand il n'est pas joignable sur le LAN.
# ~/.ssh/config (local, jamais dans le dépôt) — extraits, adresses remplacées par des marqueurs
Match originalhost zeta-secure !exec "nc -z -w1 <IP_PC4_LAN> 22 >/dev/null 2>&1"
HostName [WG_PC4] # DOIT précéder "Host zeta-secure" (première valeur gagnante)
Host zeta-<NOM> # bloc de base : IP LAN
HostName <IP_LAN>
User hprzeta
IdentityFile ~/.ssh/zeta_cluster
IdentitiesOnly yes
Host zeta-bastion-wg # saut : le bastion par le tunnel
HostName [WG_PC4]
User hprzeta
IdentityFile ~/.ssh/zeta_cluster
IdentitiesOnly yes
Match originalhost zeta-<NOM> !exec "nc -z -w1 <IP_LAN> 22 >/dev/null 2>&1"
ProxyJump zeta-bastion-wg # nœud injoignable en direct -> saut par le bastion
Host zeta-* # en dernier : timeouts courts
ConnectTimeout 5
ServerAliveInterval 15
ServerAliveCountMax 3
Pourquoi nc plutôt qu'un ping du tunnel : on teste la joignabilité de la cible elle-même, pas un
indice de localisation. Un ping du bastion se trompe si le tunnel est actif à la maison (saut inutile)
ou monté mais mort en déplacement (timeout de 2 minutes).
À savoir : le >/dev/null 2>&1 est obligatoire (sinon nc affiche l'adresse à chaque connexion) ;
ssh -G <alias> exécute le nc (reflète le réseau du moment) ; ne jamais mettre
StrictHostKeyChecking no (la clé d'hôte protège du cas « autre LAN avec la même plage d'adresses »).
Forcer le saut : ssh -J zeta-bastion-wg <alias>. Le transfert TCP doit être autorisé sur le bastion.
Test. À la maison : ssh -G <alias> | grep -i proxyjump ne renvoie rien. En déplacement (tunnel
actif) : il renvoie proxyjump zeta-bastion-wg, puis ssh <alias> true répond en quelques secondes.
Retour arrière : restaurer la sauvegarde datée de ~/.ssh/config.
- IP fixe dans la plage, clé publique
zeta_clusterdansauthorized_keys,sshdactif, port 22 ouvert. - Dans
~/.ssh/config: un blocHost zeta-<NOM>(§5.1) avant lesMatch, puis leMatch originalhostcorrespondant avant le bloc finalHost zeta-*. Le nom doit commencer parzeta-. - Test à blanc : à la maison
ssh -G zeta-<NOM>(IP LAN, aucun saut) puisssh zeta-<NOM> true; à distance (tunnel actif)ssh zeta-<NOM> true. Première connexion : confirmer la clé d'hôte.
- Désactiver l'auto-connexion de Proton VPN au démarrage (sinon il recoupe l'IPv6 à chaque allumage en déplacement, dans ton dos).
- Réflexe déplacement : Proton OFF avant
zeta-cluster. - Diagnostic toujours dans l'ordre (§4) : IPv6 → VPN tiers → endpoint → tunnel.
- Ne jamais modifier l'onglet IPv6 de la connexion wg0 (réglé « Désactiver » = normal : c'est l'IPv6 interne du tunnel, sans rapport avec l'IPv6 du réseau physique).
-
wg_auto.shv2 en place = plus de spam quand il n'y a pas d'IPv6.
-
Diagnostic-WireGuard-Hotspot — historique complet des incidents d'accès distant
(règle IPv6 box périmée, forwarding PC4,
AllowedIPs, tunnel non résilient en déplacement, VPN tiers §9) — ce guide-ci est la procédure de référence à jour, l'autre reste le journal d'incidents détaillé. - Architecture-Cluster-Zeta — chaîne d'accès distant complète, rôle de bastion de PC4.
- Guide-Linux-Commandes — §27-§28, commandes réseau et diagnostic IPv6/VPN tiers.
- STACK — avertissement Proton VPN dans la fiche cluster.
Guide-WireGuard-Acces-Distant.md · wiki racine · branche master · hprzeta · MAJ 2026-09-05 · 222 lignes