Le VPN se reconnecte en conduisant : changement de radio ou d’IP ?

L’appel se coupe quand vous passez la sortie de la ville, et l’icône VPN disparaît au même instant. Il est tentant de consigner cela comme « le changement d’antenne a tué le tunnel ». Deux choses différentes se sont produites, et une seule concerne les antennes. Un transfert radio peut laisser votre adresse IP, votre route par défaut et votre session parfaitement intacts, alors qu’un vrai changement d’adresse brisera tout tunnel qui ne peut pas le suivre. Comparer la façon dont les clients traitent ce second cas est l’exercice utile, car il vous dit si vous voyez un comportement conçu ou un bug.

Un changement d’antenne n’est pas forcément un changement d’adresse

Les réseaux mobiles maintiennent la session de paquets pendant les transferts tant que l’ancre de mobilité de l’opérateur reste la même. La liaison radio change, le tunnel ne s’en aperçoit pas, et aucune reconnexion ne devrait apparaître dans un journal. C’est le cas ordinaire pour un déplacement à l’intérieur d’une ville.

Ce qui change l’adresse, c’est un déplacement entre ancres, un basculement du Wi-Fi vers le cellulaire ou un rétablissement du tunnel côté opérateur après une longue interruption. Ces événements remplacent l’adresse source que portent vos paquets, et un pair VPN voit un pair qui a bougé.

La conséquence pratique est que le déplacement n’est pas une preuve. Un appareil qui a parcouru quarante kilomètres peut avoir gardé une seule adresse tout du long, et un appareil immobile peut avoir changé d’adresse deux fois parce que le réseau l’a décidé. Enregistrer l’événement est le seul moyen de les distinguer.

Deux conceptions : déplacer le tunnel ou le reconstruire

Les clients diffèrent par l’importance qu’ils accordent au fait que la source externe a changé. Certains lient le tunnel à l’adresse sur laquelle il a été construit et exigent un rétablissement complet. D’autres authentifient chaque paquet indépendamment et se contentent de mettre à jour l’endroit où ils envoient les réponses.

La ligne du haut explique beaucoup de rapports confus. WireGuard n’a aucune session à casser : chaque paquet porte l’index du pair et est authentifié, donc un paquet valide arrivant d’une nouvelle adresse vient par définition de ce pair, et l’extrémité enregistrée le suit. Un client qui affiche « connecté » en continu pendant un trajet dit la vérité.

La ligne du bas n’est pas un défaut non plus. Reconstruire la session réexécute l’authentification contre l’adresse actuelle, ce qui est exactement ce que vous voulez quand l’ancienne adresse peut désormais appartenir à quelqu’un d’autre.

Observez l’événement plutôt que le mouvement

Sous Android, le sous-système de connectivité signale les changements de réseau comme des événements, et ce sont eux que vous devez corréler avec le comportement du client. Le vidage est verbeux, mais les parties pertinentes sont le réseau par défaut et son adresse :

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

Côté serveur, il existe une mesure directe pour le cas de l’itinérance. WireGuard stocke la dernière extrémité authentifiée pour chaque pair, donc un changement d’adresse apparaît comme une valeur modifiée plutôt que comme une reconnexion :

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Comparez l’extrémité avant et après le trajet. Si l’adresse et le port sont inchangés, le tunnel n’a jamais eu à faire quoi que ce soit et la reconnexion est venue d’ailleurs, généralement de l’application. Si l’extrémité a changé tandis que l’horodatage de la poignée de main restait proche de son intervalle normal de renouvellement de clé, le tunnel a bougé au lieu de redémarrer.

Un redémarrage se voit autrement : l’horodatage de la poignée de main revient au moment de la reconnexion, et le client journalise une séquence d’initialisation plutôt qu’une continuation silencieuse.

Quand la reconnexion est le comportement correct

Traiter chaque reconnexion comme une panne conduit à des configurations qui maintiennent des sessions mortes en vie. Un pair dont l’adresse a changé parce que le réseau l’a réattribuée ne devrait pas continuer à recevoir du trafic pour l’ancienne correspondance, et un client qui continue silencieusement peut finir par envoyer dans un trou noir pendant que l’icône reste verte.

Comparez les deux échecs du point de vue de l’utilisateur. Une reconnexion coûte quelques secondes et une réauthentification. Un tunnel obsolète coûte une application qui se bloque sans erreur, ce qui est bien plus difficile à expliquer et bien plus susceptible d’être signalé comme « internet est cassé ».

Une question de politique se cache aussi dessous. Pendant l’écart entre la perte d’un chemin et l’établissement d’un autre, certains clients reviennent à envoyer le trafic directement. L’éviter est un contrôle distinct de la reprise automatique, et un client peut être bon dans l’un et mauvais dans l’autre. Décidez ce dont vous avez besoin avant de régler l’un ou l’autre.

Notez la séquence observée

Un rapport utile nomme la source de l’événement : un changement de réseau par défaut avec une nouvelle adresse, un basculement du Wi-Fi vers le cellulaire, ou un transfert sans aucun changement d’adresse. Il indique ensuite ce que le client a fait, avec l’horodatage côté serveur plutôt que de mémoire.

Si le tunnel a bougé, dites-le et notez la nouvelle famille d’extrémités. S’il s’est rétabli, notez si l’authentification a réussi du premier coup et combien de temps l’écart a duré. Ces trois faits distinguent une conception mobile saine d’un client qui oscille entre les réseaux.

Et évitez l’expression « changement d’antenne » sauf si le journal de l’appareil l’établit réellement. La documentation Android sur la connectivité décrit les rappels qui distinguent la disponibilité d’un changement de réseau par défaut, et c’est cette distinction dont votre rapport a besoin. Tout le reste est une histoire de conduite.