Un nouveau client hotspot bloqué sur l’obtention d’une IP n’est pas une panne du VPN

Un téléphone rejoint le point d’accès, reste sur « Obtention de l’adresse IP » et finit par abandonner. La conclusion naturelle est que le VPN du téléphone interfère avec le DNS, alors les gens se mettent à modifier les résolveurs et les règles ajoutées. C’est la mauvaise étape. Le client n’a jamais reçu d’adresse locale, et sans elle il n’a ni passerelle, ni résolveur, ni rien à transférer, donc aucun réglage VPN sur le téléphone hôte ne peut expliquer la panne. L’association, l’attribution d’une adresse locale et le transfert sortant sont trois étapes distinctes, et seule la dernière concerne le tunnel.

Les trois étapes, et celle où vous êtes

L’association vient d’abord : le client rejoint le réseau sans fil du point d’accès. Un mot de passe erroné, une incompatibilité WPA3 ou un problème de compatibilité radio échouent ici, et le client le dit généralement. L’attribution d’adresse vient ensuite : pour IPv4 le client demande un bail et reçoit une adresse plus les réglages locaux de passerelle, tandis qu’IPv6 utilise normalement les annonces de routeur plutôt que DHCP, comme le décrit la documentation AOSP sur le tethering. L’accès sortant vient en troisième : le téléphone hôte transfère le trafic autorisé vers le chemin amont qu’il a choisi, qui peut être ou ne pas être son tunnel.

Le libellé affiché sur le client vous indique l’étape. Bloqué sur l’obtention d’une adresse, c’est la deuxième étape, avant qu’un paquet ne parte vers Internet. Connecté, avec une adresse, mais rien ne se charge, c’est la troisième étape, où le routage, les noms et la couverture du tunnel comptent tous. Diagnostiquer la troisième étape alors que le client est bloqué à la deuxième, c’est ainsi qu’un problème de bail de cinq minutes devient un après-midi de modifications DNS.

Le mythe : un VPN routé transforme le DHCP local en requête distante

Un tunnel routé déplace les paquets IP pour les destinations qu’il sélectionne. Une découverte DHCP est une diffusion sur le segment propre du point d’accès, et le service de tethering du téléphone y répond localement, ce qui explique pourquoi le client peut obtenir une adresse pendant que le tunnel est actif. Seule une conception délibérément pontée ou relayée envoie cet échange ailleurs, et c’est un autre montage avec une autre signature de panne.

Donc « le serveur VPN ne répond pas au DHCP » n’est pas un diagnostic, c’est une erreur de modèle. Le courtier local est sur le téléphone. S’il cesse de répondre, les raisons sont locales : le service de tethering, la limite de clients, le pool de baux ou un client qui n’a jamais terminé correctement l’association. Aucune de ces causes ne vit du côté distant du tunnel.

Ce que prouve réellement un client existant qui fonctionne

Si un ordinateur portable déjà connecté fonctionne encore alors que le nouveau téléphone non, le point d’accès et le chemin amont sont globalement vivants. Cette comparaison est utile et elle ne prouve pas quel composant est en cause, car le client qui fonctionne peut simplement conserver un bail antérieur au changement et le renouveler discrètement.

Deux limites locales méritent d’être vérifiées pendant que vous y êtes. Le point d’accès sert un pool de baux fini et une limite de clients configurable, donc un appareil qui s’est joint puis s’est endormi peut conserver une adresse pendant qu’un nouveau attend. Et un client qui se souvient d’une configuration statique d’un autre réseau ne demandera pas de bail du tout, ce qui de l’extérieur semble identique et se corrige sur le client, pas sur le téléphone.

Gardez la comparaison locale et réversible

Sur un appareil où la politique le permet, comparez une jointure de nouveau client avec le tunnel inactif puis actif, en gardant le point d’accès et le client inchangés par ailleurs. Notez les versions du téléphone et du client, le profil choisi et l’étape exacte qui a échoué. Sur un téléphone géré, demandez la comparaison approuvée plutôt que de désactiver l’application pour obtenir un test plus propre.

Une défaillance de bail cohérente et dépendante du tunnel est une preuve utile sur une politique locale ou une interaction d’implémentation. Ce n’est pas une licence pour vider chaque règle de transfert et de NAT de l’appareil. Ces règles protègent du trafic sans rapport, et une acceptation large du transfert n’explique pas pourquoi un service DHCP local a cessé de répondre.

Ne masquez pas non plus un bail manquant avec une adresse statique devinée. Une configuration statique délibérée exige le vrai sous-réseau, la passerelle, le plan d’allocation et une vérification des collisions. Changer le DNS du client n’en fournit aucun, et elle laisse l’appareil suivant avec la même panne.

Ce qu’un bail ne prouve pas

Obtenir une adresse prouve l’admission au réseau local, pas la protection par le tunnel du téléphone. Une fois que le client détient un bail, évaluez le chemin descendant pour lui-même : le trafic du client passe-t-il réellement par le téléphone, les résolutions se font-elles là où vous l’attendez, et l’adresse extérieure correspond-elle à la sortie voulue ? Ce sont des questions de troisième étape et elles méritent leur propre test plutôt que d’être repliées dans la jointure.

Traitez les étapes dans l’ordre et la panne cesse de se déplacer. Un client bloqué sur l’obtention d’une adresse est une question locale de tethering ; un client avec une adresse et sans pages est une question de transfert ou de noms ; un client avec des pages et la mauvaise sortie est une question de couverture du tunnel. Les garder séparés, c’est l’essentiel du débogage.