Un client nou de punt d'accés encallat a obtenir una IP no és una fallada de la VPN

Un telèfon s'uneix al punt d'accés, es queda a «Obtenint una adreça IP» i finalment es rendeix. La conclusió natural és que la VPN del telèfon interfereix amb el DNS, així que la gent comença a editar resolutors i regles afegides. Aquesta és l'etapa equivocada. El client no va rebre mai una adreça local, i sense una no té portal, ni resolutor, ni res per reenviar, o sigui que cap paràmetre de la VPN al telèfon amfitrió pot explicar la fallada. L'associació, l'assignació d'adreça local i el reenviament són tres etapes separades, i només l'última implica el túnel.

Les tres etapes, i en quina sou

Primer ve l'associació: el client s'uneix a la xarxa sense fil del punt d'accés. Una contrasenya incorrecta, un desajust de WPA3 o un problema de compatibilitat de ràdio fallen aquí, i el client normalment ho diu. Segon ve l'assignació d'adreça: per a IPv4 el client demana un arrendament i rep una adreça més paràmetres locals de portal, mentre que IPv6 normalment fa servir anuncis d'encaminador en lloc de DHCP, tal com descriu la documentació d'AOSP sobre tethering. Tercer ve l'accés cap enfora: el telèfon amfitrió reenvia el trànsit permès cap al camí ascendent que hagi triat, que pot ser o no el seu túnel.

El text del client us diu l'etapa. Encallat a obtenir una adreça és la segona etapa, abans que cap paquet surti cap a internet. Connectat, amb adreça, però sense que carregui res és la tercera etapa, on tot importa: encaminament, noms i cobertura del túnel. Diagnosticar la tercera etapa mentre el client està encallat a la segona és com un problema d'arrendament de cinc minuts es converteix en una tarda d'edicions de DNS.

El mite: una VPN encaminada converteix el DHCP local en una petició remota

Un túnel encaminat mou paquets IP per a les destinacions que selecciona. Un descobriment DHCP és una difusió al mateix segment del punt d'accés, i el servei de tethering del telèfon hi respon localment, i per això el client pot obtenir una adreça mentre el túnel és actiu. Només un disseny pont o relé deliberat envia aquest intercanvi a un altre lloc, i això és un altre muntatge amb una altra signatura de fallada.

Així que «el servidor VPN no respon al DHCP» no és un diagnòstic, és un error de model. El corredor local és al telèfon. Si deixa de respondre, les raons són locals: el servei de tethering, el límit de clients, el pool d'arrendaments o un client que mai va completar bé l'associació. Cap d'aquests viu al costat remot del túnel.

Què demostra realment que un client existent funcioni

Si un portàtil que ja estava connectat continua funcionant mentre el telèfon nou no, el punt d'accés i el camí ascendent estan vius en general. Aquesta comparació és útil i no és una prova de quin component té la culpa, perquè el client que funciona pot simplement retenir un arrendament d'abans del canvi i renovar-lo en silenci.

Val la pena comprovar dos límits locals mentre hi sou. El punt d'accés serveix un pool finit d'arrendaments i un límit configurable de clients, així que un dispositiu que es va unir i va dormir pot retenir una adreça mentre un de nou espera. I un client que recorda una configuració estàtica d'una altra xarxa no demanarà cap arrendament, cosa que des de fora sembla idèntica i es corregeix al client, no al telèfon.

Mantingueu la comparació local i reversible

En un dispositiu on la política ho permet, compareu una unió de client nou amb el túnel inactiu i després actiu, mantenint el punt d'accés i el client altrament sense canvis. Anoteu les versions del telèfon i del client, el perfil seleccionat i l'etapa exacta que va fallar. En un telèfon gestionat, demaneu la comparació aprovada en lloc de desactivar l'aplicació per obtenir una prova més neta.

Una fallada d'arrendament consistent dependent del túnel és una evidència útil sobre política local o una interacció d'implementació. No és una llicència per buidar cada regla de reenviament i NAT del dispositiu. Aquestes regles protegeixen trànsit no relacionat, i una acceptació àmplia de reenviament no explica per què un servei DHCP local va deixar de respondre.

Tampoc no tapeu un arrendament que falta amb una adreça estàtica suposada. Una configuració estàtica deliberada necessita la subxarxa real, el portal, el pla d'assignació i una comprovació de col·lisions. Canviar el DNS del client no en proporciona cap, i deixa el dispositiu següent amb la mateixa fallada.

Què no demostra un arrendament

Obtenir una adreça demostra admissió a la xarxa local, no protecció pel túnel del telèfon. Un cop el client té un arrendament, avalueu el camí descendent pel seu compte: el trànsit del client passa realment pel telèfon, les consultes es resolen on espereu, i l'adreça exterior coincideix amb la sortida que volíeu? Són preguntes de la tercera etapa i es mereixen la seva pròpia prova en lloc de plegar-se dins de la unió.

Feu les etapes en ordre i la fallada deixa de moure's. Un client encallat a obtenir una adreça és una qüestió local de tethering; un client amb adreça i sense pàgines és una qüestió de reenviament o de noms; un client amb pàgines i la sortida equivocada és una qüestió de cobertura del túnel. Mantenir-los separats és la major part de la depuració.