Um cliente novo de hotspot preso em «Obtendo IP» não é falha da VPN

Um telefone associa-se ao hotspot, fica em «Obtendo endereço IP» e acaba desistindo. A conclusão natural é que a VPN do telefone interfere no DNS, então as pessoas começam a editar resolvedores e regras acrescentadas. É a etapa errada. O cliente nunca recebeu um endereço local, e sem um não tem gateway, nem resolvedor, nem nada para encaminhar, portanto nenhuma configuração de VPN no telefone anfitrião explica a falha. Associação, atribuição de endereço local e encaminhamento são três etapas separadas, e somente a última envolve o túnel.

As três etapas, e em qual você está

Primeiro vem a associação: o cliente entra na rede sem fio do hotspot. Uma palavra-passe errada, uma incompatibilidade de WPA3 ou um problema de compatibilidade de rádio falham aqui, e o cliente costuma dizê-lo. Segundo vem a atribuição de endereço: para IPv4 o cliente pede uma concessão e recebe um endereço mais configurações locais de gateway, enquanto IPv6 normalmente usa anúncios de router em vez de DHCP, como descreve a documentação do AOSP sobre tethering. Terceiro vem o acesso para fora: o telefone anfitrião encaminha o tráfego permitido para o caminho ascendente que escolheu, que pode ser ou não o seu túnel.

O texto no cliente informa a etapa. Preso a obter um endereço é a segunda etapa, antes de qualquer pacote sair para a internet. Conectado, com endereço, mas nada carrega é a terceira etapa, onde roteamento, nomes e cobertura do túnel importam. Diagnosticar a terceira etapa enquanto o cliente está preso na segunda é como um problema de concessão de cinco minutos vira uma tarde de edições de DNS.

O mito: uma VPN encaminhada transforma o DHCP local em pedido remoto

Um túnel encaminhado move pacotes IP para os destinos que seleciona. Uma descoberta DHCP é uma difusão no próprio segmento do hotspot, e o serviço de tethering no telefone responde localmente, por isso o cliente pode obter um endereço enquanto o túnel está ativo. Apenas um desenho deliberadamente em ponte ou retransmitido envia essa troca para outro lugar, e isso é outra disposição com outra assinatura de falha.

Assim, «o servidor VPN não responde ao DHCP» não é diagnóstico, é erro de modelo. O intermediário local está no telefone. Se ele parar de responder, as razões são locais: o serviço de tethering, o limite de clientes, o conjunto de concessões ou um cliente que nunca concluiu a associação corretamente. Nada disso vive do lado remoto do túnel.

O que um cliente existente a funcionar realmente prova

Se um portátil que já estava ligado continua a funcionar enquanto o telefone novo não, o hotspot e o caminho ascendente estão em geral vivos. Essa comparação é útil e não é prova de qual componente tem culpa, porque o cliente que funciona pode simplesmente manter uma concessão de antes da mudança e renová-la em silêncio.

Vale a pena verificar dois limites locais enquanto está lá. O hotspot serve um conjunto finito de concessões e um limite configurável de clientes, então um dispositivo que se associou e dormiu pode reter um endereço enquanto um novo espera. E um cliente que se lembra de uma configuração estática de outra rede não pedirá concessão alguma, o que de fora parece idêntico e se corrige no cliente, não no telefone.

Mantenha a comparação local e reversível

Num dispositivo onde a política o permite, compare uma associação de cliente novo com o túnel inativo e depois ativo, mantendo o hotspot e o cliente inalterados no resto. Anote as versões do telefone e do cliente, o perfil escolhido e a etapa exata que falhou. Num telefone gerido, peça a comparação aprovada em vez de desativar a aplicação para obter um teste mais limpo.

Uma falha de concessão consistente e dependente do túnel é evidência útil sobre política local ou interação de implementação. Não é licença para limpar todas as regras de encaminhamento e NAT do dispositivo. Essas regras protegem tráfego não relacionado, e uma aceitação ampla de encaminhamento não explica por que um serviço DHCP local parou de responder.

Também não tape uma concessão em falta com um endereço estático adivinhado. Uma configuração estática deliberada exige a sub-rede real, o gateway, o plano de alocação e uma verificação de colisões. Alterar o DNS do cliente não fornece nada disso, e deixa o próximo dispositivo com a mesma falha.

O que uma concessão não prova

Obter um endereço prova a admissão na rede local, não a proteção pelo túnel do telefone. Depois de o cliente ter uma concessão, avalie o caminho descendente por si só: o tráfego do cliente passa realmente pelo telefone, as consultas resolvem-se onde espera, e o endereço exterior corresponde à saída que pretendia? São perguntas da terceira etapa e merecem o seu próprio teste em vez de serem dobradas na associação.

Trabalhe as etapas por ordem e a falha deixa de se mover. Um cliente preso a obter um endereço é uma questão local de tethering; um cliente com endereço e sem páginas é uma questão de encaminhamento ou de nomes; um cliente com páginas e a saída errada é uma questão de cobertura do túnel. Mantê-los separados é a maior parte da depuração.