Un cliente novo atascado en obter IP non é un fallo da VPN

Un teléfono únese ao punto de acceso, queda en «Obtendo enderezo IP» e acaba rendéndose. A conclusión natural é que a VPN do teléfono interfire co DNS, así que a xente comeza a editar resolutores e regras engadidas. Esa é a etapa equivocada. O cliente nunca recibiu un enderezo local, e sen un non ten portal, nin resolutor, nin nada que reenviar, así que ningún axuste de VPN no teléfono anfitrión pode explicar o fallo. A asociación, a asignación de enderezo local e o reenvío son tres etapas separadas, e só a última implica o túnel.

As tres etapas, e en cal estás

Primeiro vén a asociación: o cliente únese á rede sen fíos do punto de acceso. Un contrasinal incorrecto, un desaxuste de WPA3 ou un problema de compatibilidade de radio fallan aquí, e o cliente normalmente dixo. Segundo vén a asignación de enderezo: para IPv4 o cliente pide un arrendamento e recibe un enderezo máis axustes locais de portal, mentres que IPv6 normalmente usa anuncios de enrutador en lugar de DHCP, como describe a documentación de AOSP sobre tethering. Terceiro vén o acceso cara a fóra: o teléfono anfitrión reenvía o tráfico permitido á ruta ascendente que elixise, que pode ser ou non o seu túnel.

O texto do cliente diche a etapa. Atascado en obter un enderezo é a segunda etapa, antes de que saia ningún paquete cara a internet. Conectado, con enderezo, pero sen que cargue nada é a terceira etapa, onde importan o enrutamento, os nomes e a cobertura do túnel. Diagnosticar a terceira etapa mentres o cliente está atascado na segunda é como un problema de arrendamento de cinco minutos se converte nunha tarde de edicións de DNS.

O mito: unha VPN encamiñada converte o DHCP local nunha petición remota

Un túnel encamiñado move paquetes IP para os destinos que selecciona. Un descubrimento DHCP é unha difusión no propio segmento do punto de acceso, e o servizo de tethering do teléfono respóndelle localmente, por iso o cliente pode obter un enderezo mentres o túnel está activo. Só un deseño ponte ou retransmitido deliberadamente envía ese intercambio a outro sitio, e iso é outra disposición con outra sinatura de fallo.

Así que «o servidor VPN non responde ao DHCP» non é un diagnóstico, é un erro de modelo. O intermediario local está no teléfono. Se deixa de responder, as razóns son locais: o servizo de tethering, o límite de clientes, o conxunto de arrendamentos ou un cliente que nunca completou ben a asociación. Nada diso vive no lado remoto do túnel.

Que demostra en realidade que un cliente existente funcione

Se un portátil que xa estaba conectado segue funcionando mentres o teléfono novo non, o punto de acceso e a ruta ascendente están vivos en xeral. Esa comparación é útil e non é proba de que compoñente ten a culpa, porque o cliente que funciona pode simplemente reter un arrendamento de antes do cambio e renovalo en silencio.

Paga a pena comprobar dous límites locais mentres estás alí. O punto de acceso serve un conxunto finito de arrendamentos e un límite configurable de clientes, así que un dispositivo que se uniu e durmiu pode reter un enderezo mentres un novo espera. E un cliente que recorda unha configuración estática doutra rede non pedirá ningún arrendamento, o que desde fóra parece idéntico e corríxese no cliente, non no teléfono.

Manteña a comparación local e reversible

Nun dispositivo onde a política o permita, compara unha unión de cliente novo co túnel inactivo e despois activo, mantendo o punto de acceso e o cliente sen cambios polo demais. Anota as versións do teléfono e do cliente, o perfil seleccionado e a etapa exacta que fallou. Nun teléfono xestionado, solicita a comparación aprobada en lugar de desactivar a aplicación para obter unha proba máis limpa.

Un fallo de arrendamento consistente e dependente do túnel é unha evidencia útil sobre política local ou unha interacción de implementación. Non é unha licenza para baleirar cada regra de reenvío e NAT do dispositivo. Esas regras protexen tráfico non relacionado, e unha aceptación ampla de reenvío non explica por que un servizo DHCP local deixou de responder.

Tampouco tapes un arrendamento ausente cun enderezo estático suposto. Unha configuración estática deliberada necesita a subrede real, o portal, o plan de asignación e unha comprobación de colisións. Cambiar o DNS do cliente non achega nada diso, e deixa o seguinte dispositivo co mesmo fallo.

Que non demostra un arrendamento

Obter un enderezo demostra a admisión á rede local, non a protección polo túnel do teléfono. Unha vez que o cliente ten un arrendamento, avalia a ruta descendente por si soa: o tráfico do cliente pasa realmente polo teléfono, resólvense as consultas onde esperas e o enderezo exterior coincide coa saída que pretendías? Son preguntas da terceira etapa e merecen a súa propia proba en lugar de preguntarse dentro da unión.

Traballa as etapas en orde e o fallo deixa de moverse. Un cliente atascado en obter un enderezo é unha cuestión local de tethering; un cliente con enderezo e sen páxinas é unha cuestión de reenvío ou de nomes; un cliente con páxinas e a saída equivocada é unha cuestión de cobertura do túnel. Mantelos separados é a maior parte da depuración.