Skip to content

Diagnostic WireGuard Hotspot

Jump to bottom
hprzeta edited this page Sep 5, 2026 · 10 revisions

Fichier : Diagnostic-WireGuard-Hotspot.md · Dossier : wiki (racine) Branche : master (wiki) · Auteur : hprzeta · MAJ : 2026-09-05

Diagnostic — Panne récurrente d'accès distant WireGuard ⚠️ INCIDENT RÉCURRENT

📘 Procédure de dépannage à jour : Guide-WireGuard-Acces-Distant (créé le 05/09/2026, intègre le cas VPN tiers §9 ci-dessous). Ce fichier-ci reste le journal détaillé des incidents (causes racines, correctifs, chronologie) ; pour la marche à suivre en cas de panne, se référer d'abord au guide.

1. Résumé — quatre occurrences distinctes

Le même symptôme (« aucun accès distant au cluster ») s'est produit plusieurs fois, pour des causes racines différentes. Les modes de défaillance sont désormais identifiés et documentés séparément ci-dessous (§2 à §5 et §9), avec un mode plus ancien (§4, juillet) qui reste possible mais moins probable statistiquement.

Occurrence Symptôme Cause racine Statut
Juillet 2026 (05/07) Handshake OK, aucune donnée ne passe AllowedIPs vide pour le peer PC1 sur PC4 ✅ Résolu — voir §4
Août 2026 (22/08) Aucun handshake du tout Règle IPv6 de la box pointant vers une adresse PC4 périmée ✅ Résolu — voir §5.3
Août 2026 (22/08) Handshake OK, PC2/PC3 injoignables (PC4 seul répond) net.inet.ip.forwarding=0 sur PC4 ✅ Résolu — voir §5.4
Août 2026 (30/08) Retour de déplacement : wg0 monté sans IP, PC2/PC3 injoignables 4 causes cumulées (boot prématuré, script de reprise non fiable, collision de sous-réseau, IP LAN en dur) ✅ Résolu — voir §8
Septembre 2026 (05/09) En déplacement : aucune IPv6 globale (fe80:: seul), donc aucun handshake VPN tiers (Proton VPN) qui interceptait/bloquait l'IPv6 côté client ✅ Résolu — voir §9

En déplacement, vérifier d'abord un VPN tiers actif (§9) ; à la maison, le mode §2 (règle IPv6 box périmée) reste le plus probable. Ce dernier se reproduira à chaque fois que l'identifiant d'interface ou le préfixe IPv6 de PC4 change côté box — c'est un mode de défaillance structurel de cette architecture, pas un incident isolé. Procédure de dépannage à jour, dans l'ordre : Guide-WireGuard-Acces-Distant §4.

2. Mode de défaillance n°1 (le plus probable) — règle IPv6 box périmée

Mécanisme

La règle « Réseau v6 » de la box SFR (Sécurité → Réseau → Réseau v6) ouvre le port UDP 51820 vers une adresse IPv6 complète et figée de PC4, saisie manuellement. Cette adresse n'est pas mise à jour automatiquement quand l'adresse IPv6 de PC4 change — contrairement à l'enregistrement DuckDNS (AAAA), qui lui suit automatiquement via duck.sh en crontab.

Résultat : DNS et box peuvent diverger silencieusement. Le client résout un nom qui pointe vers la bonne adresse, mais la box filtre encore sur l'ancienne.

Pourquoi ça se reproduit

L'adresse IPv6 de PC4 (OpenBSD, génération RFC 7217 stable-privacy) dépend de l'interface réseau en plus du préfixe délégué. Elle change donc dans deux cas, tous deux hors du contrôle du wiki opérationnel :

  1. Changement de préfixe délégué par SFR (renouvellement DHCPv6-PD côté FAI, sans action de l'utilisateur) — cas générique, peut survenir à tout moment.
  2. Changement d'interface physique sur PC4 — observé le 16/08/2026 lors de la migration matérielle Dell Dimension 4500 → Compaq CQ58 (Migration-PC4-Compaq-CQ58-20260816) : même préfixe /64 ([IPV6]/64), mais identifiant d'interface différent, donc adresse hôte différente.

Dans les deux cas, DuckDNS suit (le script lit l'adresse courante sur l'interface), mais la règle de la box, saisie à la main, ne suit pas. C'est la cause identifiée le 22/08/2026 :

Règle box (avant, obsolète) : [IPV6]
PC4 réel (après)             : [IPV6]

Confirmation par élimination : pare-feu IPv6 de la box désactivé → handshake immédiat. Règle corrigée (WireGuard-ipV6-Newpc4) → handshake OK avec pare-feu réactivé.

Correction appliquée

Nouvelle règle « Réseau v6 » WireGuard-ipV6-Newpc4 sur la box (UDP, 51820→51820, destination = adresse IPv6 courante de PC4, Sur). L'ancienne règle WireGuard-ipV6 est laissée Off (conservée pour historique, pas de conflit — une règle désactivée n'est pas évaluée par le pare-feu).

⚠️ Sur l'interface de la box, le bouton « Créer une règle » de la section Entrée de filtrage (IPv6) ne concerne que l'ICMP. Les ouvertures UDP se font dans Sécurité → Réseau → Réseau v6, pas dans le filtrage ICMP.

3. Mode de défaillance n°2 — routage IPv6 désactivé sur PC4

Une fois le tunnel monté (handshake OK), [WG_PC4] (PC4 lui-même) répondait, mais [IP_PC2] (PC2) et [IP_PC3] (PC3) restaient injoignables.

sysctl net.inet.ip.forwarding      # → 0
pfctl -sr | grep -i nat-to         # → règle nat-to présente et correcte

Le NAT était en place côté pf, mais OpenBSD ne route pas entre interfaces par défaut : net.inet.ip.forwarding doit être explicitement activé. Absent de la session de juillet 2026 — cause distincte de celle de §2, à ne pas confondre.

Correction (persistante) :

# /etc/sysctl.conf sur PC4
net.inet.ip.forwarding = 1

À vérifier après toute réinstallation ou migration matérielle de PC4 (ce réglage ne survit pas à une réinstallation depuis zéro).

4. Mode de défaillance n°3 (historique, juillet 2026) — AllowedIPs vide

Cause de la panne du 05/07/2026, résolue et normalement non récurrente sauf erreur de configuration manuelle future sur /etc/hostname.wg0.

4.1 Contexte

Test de wg_auto.sh en mode déplacement, connexion via hotspot mobile (Port_Armel). Objectif : valider la bascule automatique maison/déplacement de PC1 en conditions réelles.

4.2 Principe — handshake vs transport de données

Un tunnel WireGuard fonctionne en deux temps distincts, qui peuvent être bloqués indépendamment l'un de l'autre par un réseau intermédiaire :

  1. Handshake : poignée de main cryptographique initiale + paquets keepalive périodiques. Paquets très petits et peu fréquents.
  2. Transport de données : trafic applicatif réel (ping, SSH, synchronisation cluster). Paquets plus gros et/ou plus soutenus dans le temps.

Un opérateur mobile ou un pare-feu peut laisser passer le premier tout en filtrant le second. C'est un piège classique : un handshake réussi ne garantit jamais que le tunnel transporte des données (cf. §7).

Dans le cas de juillet, la cause n'était en réalité ni un opérateur mobile ni un pare-feu, mais une erreur de configuration locale (§4.4). Le principe handshake/données reste néanmoins valable et a ressurgi en août (§3) sous une autre forme : forwarding désactivé plutôt que filtrage réseau.

4.3 Résultats des tests (05/07/2026, avant résolution)

Étape Résultat
Connexion hotspot mobile OK (IPv4 CGNAT + IPv6 disponible)
Tunnel wg0, endpoint IPv4 (DuckDNS) Handshake : aucune réponse (0 B received)
Endpoint basculé en IPv6 (adresse PC4 alors courante) Handshake OK (124 B puis 744 B received, keepalive stable ~3 min)
Ping [WG_PC4] (endpoint IPv6) KO — 100 % perte
SSH TCP port 22 vers [WG_PC4] KO — timeout total
Test MTU (ping -s 8) KO aussi — fragmentation écartée comme cause

Note IPv4 (correction 22/08/2026) — l'échec du handshake en IPv4 observé ici venait du hotspot mobile (CGNAT/DPI côté opérateur), pas de la box. Mais même sans ce blocage opérateur, le chemin IPv4 n'aurait de toute façon jamais fonctionné : le WAN de la box SFR est IPv6 seul (confirmé par la box elle-même : « Les configurations IPv4 ne peuvent pas fonctionner en raison de l'architecture de routage IPv6 WAN actuelle »). Toute redirection de port IPv4 sur la box est inopérante par conception, indépendamment de tout filtrage opérateur. Ne pas chercher à diagnostiquer ou réparer un chemin d'accès distant en IPv4 — seul l'endpoint IPv6 est un chemin viable.

4.4 Cause racine — AllowedIPs vide pour le peer PC1 sur PC4

En LAN maison, doas pfctl -sr sur PC4 n'a montré aucune règle bloquante — le trafic sur wg0 (ping et TCP) est bien autorisé par pf. Le vrai coupable : doas wg show wg0 a révélé deux peers :

peer: [CLE_PUB_TEL]
  allowed ips: [WG_PC1]/32, [WG_TEL]/32   ← doublon, [WG_PC1]/32 ne devrait pas être ici

peer: [CLE_PUB_PC1]   ← PC1
  allowed ips: (none)                       ← rien n'est autorisé pour PC1 !

Un /32 WireGuard ne peut appartenir qu'à un seul peer dans la table de routage du noyau. /etc/hostname.wg0 contenait une ligne wgaip [WG_PC1]/32 en trop sous le bloc wgpeer 6euaNc/..., ce qui volait l'IP [WG_PC1]/32 au peer PC1.

Pourquoi le handshake/keepalive fonctionnaient quand même : ces paquets de contrôle n'ont pas de charge IP interne, donc ils ne sont pas soumis au filtrage AllowedIPs — seul le trafic de données réel est concerné, d'où le symptôme trompeur « tunnel qui a l'air OK mais rien ne passe ».

4.5 Correctif appliqué

# Live — via wg set (remplace la liste allowed-ips de chaque peer)
doas wg set wg0 peer [CLE_PUB_TEL] allowed-ips [WG_TEL]/32
doas wg set wg0 peer [CLE_PUB_PC1] allowed-ips [WG_PC1]/32

# Persistant — retire la ligne wgaip en trop dans /etc/hostname.wg0
doas sed -i '/^wgaip [WG_PC1]\/32$/d' /etc/hostname.wg0

4.6 Retest hotspot mobile — confirmation

Test Résultat
Handshake WireGuard (IPv6) OK — 6 secondes, 604 B received
ping [WG_PC4] (PC4, gateway VPN) ✅ 0% perte, RTT 42-52 ms
SSH TCP port 22 → [WG_PC4] ✅ succeeded
ping [IP_PC2] (PC2, via tunnel) ✅ 0% perte, RTT 40-55 ms
ping [IP_PC3] (PC3, via tunnel) ✅ 0% perte, RTT 36-55 ms

4.7 Vue globale — automatisation maison / déplacement

Indépendamment des blocages réseau ponctuels, l'automatisation de wg_auto.sh elle-même fonctionne correctement dans les deux contextes (maison et déplacement), déclenchée soit par le dispatcher réseau, soit par zeta_tmux.sh au lancement du cluster.

Schéma diagnostic WireGuard hotspot Schéma automatisation wg_auto.sh

4.8 Note (16/08/2026) — captures d'écran retrouvées

Les captures d'écran liées au diagnostic WireGuard/zeta-vpn, initialement portées disparues, ont été retrouvées et archivées dans ~/projet_zeta/docs/archive/wireguard_screenshots/ (local uniquement, hors dépôt Git).

5. Session août 2026 (22/08) — chronologie détaillée

5.1 Symptôme initial

Aucun handshake WireGuard depuis l'extérieur du réseau domestique. Le cluster Zeta était inaccessible à distance (PC2, PC3, PC4 en rc=255 dans zeta_monitor.py).

5.2 Pistes écartées

Piste Verdict Preuve
Clé publique changée à la migration ❌ écartée wg show sur PC4 renvoie exactement le PublicKey du peer de wg0.conf sur PC1
pf bloque l'UDP 51820 ❌ écartée pfctl -sr : pass in on re0 proto udp from any to any port = 51820 (non qualifié en famille d'adresses → couvre IPv4 et IPv6)
Adresses IPv6 temporaires qui périment ❌ écartée PC4 (OpenBSD) publie une adresse stable RFC 7217, pas une temporaire
Doublon d'IP .54 dans la table de la box ❌ écartée Ancienne MAC en Off, sans effet sur le chemin IPv6
Cron DuckDNS absent ❌ écartée */5 * * * * /etc/duckdns/duck.sh présent dans le crontab root

5.3 Cause n°1 confirmée — voir détail complet en §2

5.4 Cause n°2 confirmée — voir détail complet en §3

5.5 Effet de bord corrigé au passage — enregistrement A DuckDNS

L'enregistrement A (IPv4) de DuckDNS était périmé et inutilisable : le script duck.sh envoie &ip= (vide), donc DuckDNS conservait indéfiniment l'ancienne valeur IPv4. wg-quick up résolvait alors le nom en IPv4 périmée, imposant un forçage manuel de l'endpoint IPv6 à chaque montage. Suppression volontaire de l'enregistrement A → la résolution part désormais directement en IPv6, sans forçage manuel.

5.6 Configuration finale de référence (22/08/2026)

Box SFR (GR140IG) :

Paramètre Valeur
Pare-feu IPv6 Activé
Pare-feu IPv4 Off (sans objet, WAN IPv6 seul)
DMZ / DMZv6 Off
Règle Réseau v6 WireGuard-ipV6-Newpc4 UDP, ports 51820→51820, dest. = adresse IPv6 courante de PC4, Sur
Ancienne règle WireGuard-ipV6 Off (conservée pour historique)
Redirection de ports IPv4 WireGuard Off — inopérante par conception, WAN IPv6 seul

DuckDNS :

Élément Valeur
Domaine [DDNS_PC4]
Enregistrement AAAA adresse courante de PC4, mise à jour automatique
Enregistrement A supprimé volontairement (§5.5)
Updater /etc/duckdns/duck.sh, crontab root, */5 * * * *

Token DuckDNS — ne jamais recopier de valeur en clair dans le wiki. Voir Migration-PC4-Compaq-CQ58-20260816 pour l'incident de token exposé et sa correction (rédaction, remplacement par <TOKEN>).

PC4 (zeta-secure, OpenBSD 7.9) — règles pf pertinentes :

block drop in all
pass in on re0 proto udp from any to any port = 51820
pass in on wg0 all flags S/SA
match out on re0 inet from [RESEAU_WG] to any nat-to (re0) round-robin
pass in on re0 inet6 proto ipv6-icmp all icmp6-type routeradv
pass in on re0 inet6 proto ipv6-icmp all icmp6-type neighbradv
pass in on re0 inet6 proto ipv6-icmp all icmp6-type neighbrsol
pass in on re0 inet6 proto ipv6-icmp all icmp6-type redir

Ces règles autorisent routeradv, neighbradv, neighbrsol, redir — mais pas echoreq. PC4 ne répond donc jamais au ping6 direct (cf. faux positif §7).

PC1 (zeta-lab, Ubuntu) — /etc/wireguard/wg0.conf :

Endpoint   = [DDNS_PC4]:51820
AllowedIPs = [RESEAU_WG], [LAN]

Bascule automatique par nm-dispatcher selon le SSID : réseau domestique → wg0 coupée (LAN direct) ; réseau externe → wg0 maintenue.

6. Procédure de vérification standard (à faire en premier)

En cas de nouvelle panne d'accès distant, tester dans cet ordre :

  1. Tester la santé réelle du tunnel (cause §8, à tester en priorité après un déplacement ou un redémarrage) :

    ping -c2 [WG_PC4]

    Un wg show qui semble sain (interface présente, handshake récent) ne prouve rien si wg0 n'a pas d'adresse IP — voir §8. En cas d'échec : sudo wg-quick down wg0 && sudo wg-quick up wg0.

  2. Comparer DNS et règle box (cause §2, la plus probable en usage sédentaire à la maison) :

    # Sur PC1
dig +short AAAA [DDNS_PC4]

    Comparer avec l'adresse de destination de la règle WireGuard-ipV6-Newpc4 dans l'interface box ([IP_BOX] → Sécurité → Réseau → Réseau v6). Si elles diffèrent → mettre la règle à jour manuellement.

  3. Vérifier le forwarding sur PC4 (cause §3), si le handshake réussit mais que seul PC4 répond :

    doas sysctl net.inet.ip.forwarding   # doit valoir 1

  4. Vérifier AllowedIPs (cause §4), si le handshake réussit mais qu'aucune donnée ne passe même avec forwarding actif :

    doas wg show wg0

Ordre de test à respecter

  1. Modifier la configuration de la box (nécessite d'être sur le LAN)
  2. Basculer sur un partage de connexion mobile
  3. Monter le tunnel et tester

Toute inversion des étapes 2 et 3 produit un faux négatif (le dispatcher coupe wg0 dès qu'il détecte le SSID domestique — cf. §7).

Précaution

Ne jamais modifier la configuration réseau de la box via le tunnel : une erreur coupe l'accès jusqu'au retour physique sur le LAN.

7. Faux positifs connus — pièges à ne pas refaire

a) nc -u ... succeeded ne prouve rien. En UDP, nc affiche « succeeded » dès qu'aucun ICMP d'erreur ne revient dans le délai. Vérifier en particulier que le test part bien de l'extérieur du LAN — un test lancé depuis le même /64 que la cible ne traverse jamais le pare-feu de la box.

b) ping6 vers PC4 échoue même quand tout va bien. Les règles pf de PC4 autorisent routeradv, neighbradv, neighbrsol, redir — mais pas echoreq (voir §5.6). PC4 ne répond donc jamais au ping direct. Le silence n'est pas un diagnostic de panne.

c) nm-dispatcher détruit wg0 en LAN — comportement normal, pas un bug. Un script nm-dispatcher sur PC1 détecte le SSID domestique et coupe volontairement le tunnel (bascule en LAN direct) :

nm-dispatcher: 🏠 MAISON — WireGuard DÉSACTIVÉ — LAN direct (PC4 joignable)
nm-dispatcher: [#] ip link delete dev wg0

Corollaire méthodologique : aucun test de tunnel n'est possible depuis le réseau domestique. Basculer systématiquement sur un partage de connexion mobile avant de tester (voir §6, ordre de test).

d) Un handshake réussi ne garantit jamais que le tunnel transporte des données. C'est le principe qui explique à la fois la panne de juillet (§4, AllowedIPs vide) et celle d'août (§3, forwarding désactivé) : dans les deux cas, les paquets de contrôle (handshake, keepalive) sont passés sans souci pendant que le trafic applicatif réel restait bloqué. Toujours valider avec un test de données réel (ping applicatif, SSH), jamais avec le seul wg show / latest handshake.

e) No route to host sur toute IP 192.168.1.x en déplacement ne signifie pas une panne cluster. PC1 est simplement hors du réseau maison. Premier réflexe : ip route | grep default ; si la passerelle diffère de celle du LAN maison, passer par le tunnel (cf. §8).

f) Un handshake vivant ne garantit ni une adresse IP sur l'interface, ni des routes correctes — variante du principe (d) pour une autre cause : en §8, wg0 avait un handshake actif mais aucune adresse. Toujours valider avec un test de données réel, jamais avec wg show seul.

g) AllowedIPs avec [LAN] collisionne dès que le réseau d'accueil utilise la même plage (cas fréquent : Free, SFR, Livebox par défaut). Un bastion en rebond pur ([RESEAU_WG] seul, cf. §8 E3) l'évite définitivement.

h) wg-quick au démarrage d'une machine Wi-Fi part souvent avant que le réseau soit prêt. Ajouter une dépendance explicite (network-online.target) évite de rejouer l'échec à chaque redémarrage (§8, E1).

8. Mode de défaillance n°4 — tunnel non résilient en déplacement (retour, boot, collision LAN)

Contexte

Le 30/08/2026, PC1 était en déplacement, connecté derrière un routeur tiers utilisant également le sous-réseau [LAN] (plage très répandue chez les box grand public). Symptôme : nœuds fixes injoignables en SSH direct (No route to host), moniteur cluster en échec sur tous les nœuds distants.

Diagnostic

Ce n'est pas une panne du cluster : les adresses 192.168.1.x visées sont celles du LAN maison. Sur un réseau d'accueil qui utilise la même plage, ssh [IP_PC2] cherche la machine sur le réseau local courant — elle n'y est pas. Premier réflexe : comparer la passerelle par défaut (ip route | grep default) à celle du LAN maison ; si elle diffère, passer par le tunnel WireGuard, pas par les IP LAN.

Le tunnel montrait un handshake récent (sudo wg show), mais l'interface wg0 n'avait aucune adresse IP — montée à moitié.

4 erreurs cumulées

# Erreur Cause Conséquence
E1 wg0 monté sans IP au démarrage wg-quick@wg0 lancé au boot avant que le Wi-Fi soit connecté → l'endpoint <hostname>.duckdns.org n'était pas résolvable → l'unité échoue après avoir créé l'interface Tunnel à moitié mort au retour de déplacement
E2 Le script de reprise automatique ne réparait pas Il testait la présence de l'interface (wg show wg0), jamais sa santé (handshake réel) Le tunnel cassé n'était jamais relancé automatiquement
E3 Collision [LAN] AllowedIPs incluait [LAN] → wg-quick ajoute une route qui avale la passerelle locale sur tout LAN d'accueil utilisant la même plage Coupe l'Internet IPv4 local en déplacement ; échec de wg-quick up au boot
E4 SSH et moniteur sur IP LAN en dur Les scripts de connexion visaient directement les IP 192.168.1.x des nœuds fixes Volets SSH et moniteur en échec en déplacement

Correctifs appliqués

  • Test de santé plutôt que de présence : le script de reprise automatique teste désormais un ping vers l'IP du bastion côté tunnel ([WG_PC4]) ; en cas d'échec, il relance wg-quick down puis up et re-teste.
  • AllowedIPs réduit à [RESEAU_WG] seul (rebond pur par le bastion) : le tunnel ne transporte plus que le sous-réseau VPN. PC2/PC3 sont atteints à travers le bastion, jamais par une route LAN directe injectée dans le tunnel — élimine la collision, quel que soit le réseau d'accueil.
  • Moniteur et session tmux via ProxyJump : les nœuds non-bastion sont contactés par ssh -J <utilisateur>@[WG_PC4] ... plutôt que par IP LAN directe ; le bastion reste joignable en direct sur [WG_PC4]. Détection automatique du contexte (tunnel up/down) pour choisir la bonne route.
  • Démarrage après le réseau : After=network-online.target + Wants=network-online.target sur l'unité wg-quick@wg0, pour éviter un montage tenté avant que l'endpoint DDNS soit résolvable.

9. Mode de défaillance n°5 (05/09/2026) — VPN tiers (Proton) intercepte l'IPv6 côté client

Contexte

En déplacement (hotspot mobile), ip -6 addr ne montrait qu'une adresse fe80:: lien-local — aucune IPv6 globale, donc aucun handshake WireGuard possible (l'endpoint DuckDNS est IPv6 seul). Piste initialement soupçonnée : opérateur mobile sans IPv6. Fausse piste — un redémarrage complet du partage de connexion (déconnexion/reconnexion réelle, confirmée dans les logs noyau) n'a rien changé : toujours aucune IPv6 globale ensuite.

Cause racine

Proton VPN, actif sur le portable, interceptait la connexion et bloquait l'IPv6 (comportement anti-fuite classique des VPN commerciaux). Le hotspot fournissait bien l'IPv6 depuis le début.

Preuve par élimination :

Proton ACTIF  : ip -6 addr show | grep -v fe80  → rien · ping6 externe → injoignable
Proton COUPÉ  : ip -6 addr show | grep -v fe80  → 2a02:...:.../64 global · ping6 → OK
                sudo wg-quick up wg0 ; ping [WG_PC4] → 0% perte, ~58 ms

Seul changement entre les deux états : Proton VPN coupé. Handshake immédiat.

Effet de bord — spam de notifications

Pendant la période sans IPv6 (Proton actif), le dispatcher réseau redéclenchait wg_auto.sh à chaque event, qui tentait de réparer un tunnel structurellement injoignable (pas d'IPv6) → boucle "tunnel MORT → réparation → échec" toutes les ~10 secondes. Ce n'était pas un bug du script : il réparait fidèlement un symptôme (pas de handshake) dont la vraie cause (Proton) lui était invisible.

Correctif appliqué

wg_auto.sh v2 : garde IPv6 globale avant toute tentative de réparation ou notification en déplacement (détail complet : Guide-WireGuard-Acces-Distant §3.4). Committé le 05/09/2026 sur Riemann_Lab_C (fix(scripts): wg_auto.sh — auto-réparation handshake + garde IPv6 avant notif/action). Backups conservés : wg_auto.sh.bak-20260905 (état 30/08), wg_auto.sh.bak-20260905-avant-v2.

Leçon

Un test répété qui échoue de la même façon ne prouve pas la même cause à chaque fois. « Ça marchait avant sur ce même hotspot » était le bon indice — la variable qui avait changé n'était pas le réseau mais un logiciel tiers actif sur le client, invisible depuis PC1 sans vérification explicite.

Voir aussi

Diagnostic-WireGuard-Hotspot.md · wiki racine · branche master · hprzeta · MAJ 2026-09-05 · 536 lignes

Clone this wiki locally