Hypothèse de chatgpt:
Android utilise une implémentation WireGuard différente, souvent encapsulée dans un socket “UDP keepalive” plus fréquent, tandis que les clients Linux et Windows utilisent un intervalle heartbeat plus long, que certaines box interrompent au-delà de 30 s.
Résultat :
→ le tunnel UDP s’établit, mais la box ferme la translation NAT avant la réponse,
→ donc aucune data ne revient, le VPN reste bloqué.
C'est pas demain la veille que ChatGPT donnera quelque chose de correct on dirait:
Le protocole Wireguard est le
MÊME pour Android, Linux, Windows
Les implémentations sont différentes, car sous Linux, il y a une partie kernel + userspace en C, Sous Windows c'est en userspace avec des versions Go (que l'on a aussi sous ... Android)
Par contre, ça peut donner des pistes : le keepalive
Avec le vieux client Windows Wireguard, ce keepalive peut se configurer de la même manière sous Linux d'ailleurs :
[Interface]
Address = 172.16.0.1/32
PrivateKey = 0Mk...8=
DNS = 172.16.0.254
[Peer]
PublicKey = B4Xt6U...k=
PresharedKey = X0...mEk=
Endpoint = XXX.XXX.XXX.XXX:43210
AllowedIPs = 172.16.0.1/24
PersistentKeepalive = 21
C'est le
PersistentKeepalive qui fait que j'envoie un KeepAlive toutes 21 secondes.
Mes différents tunnels WireGuard fonctionnent sans soucis avec la BBox 6E en tout cas.
Incidents Bouygues