A VPN funciona no Wi-Fi mas não nos dados móveis: por quê
O mesmo perfil pode funcionar em casa e falhar na rede móvel. Mude apenas a rede, anote em que etapa falha e então verifique os logins do portal e o comportamento na transferência.
Comece por uma comparação, não por uma conclusão: o mesmo telefone, o mesmo perfil, duas redes. Se o túnel falha numa e funciona na outra, a diferença está em algum ponto do caminho e não nas credenciais. Anote que tipo de falha você obtém, porque uma recusa antes do login e uma conexão que não transporta nada são problemas diferentes. Tudo abaixo pressupõe esse teste, feito mudando apenas a rede.
Uma VPN precisa da conexão subjacente; não a substitui e não pode obrigar uma operadora a transportar o que a operadora se recusa a transportar.
Mantenha o telefone fixo e mude apenas a rede
Mudar a rede e o servidor ao mesmo tempo deixa duas causas possíveis e nenhuma forma de separá-las. Compare o mesmo endpoint primeiro no Wi-Fi e depois nos dados móveis, e anote o sintoma exato a cada vez. Uma falha antes da autenticação aponta para a alcançabilidade, uma recusa de credenciais aponta para a conta, e um túnel conectado que não transporta nada aponta para roteamento ou DNS. Só o primeiro tem realmente a ver com a rede.
Uma recusa explícita no login também pertence às verificações de autenticação, mesmo que só apareça numa rede. Algumas operadoras e redes de convidados interceptam o tráfego de formas que produzem erros enganosos.
O que a rede de acesso pode ver e cobrar
A operadora que transporta o túnel observa a própria conexão: o momento, o volume e o endereço do endpoint da VPN. Criptografar a carga útil não esconde essas propriedades, e isso vale numa ligação Wi-Fi doméstica tanto quanto nos dados móveis. O que uma VPN muda é quem pode ver o quê, e a resposta é diferente em cada salto. Anote isso salto a salto em vez de descrever a conexão como privada em geral.
As cobranças são a outra diferença prática. A encapsulação, os sinais de manutenção e as novas tentativas consomem bytes, e as aplicações podem retomar uma transferência após uma mudança de rede. Também existe Wi-Fi doméstico com limite, então verifique os contadores do aparelho e o plano em vez de supor que uma das redes é ilimitada.
Logins do portal e restrições da operadora
É preciso satisfazer um portal cativo antes que o túnel alcance qualquer coisa. Reconectar a VPN não admitirá um dispositivo que a rede não autorizou, e uma política sempre ativa pode tornar o portal inacessível. Conclua primeiro o login pelo fluxo normal do navegador e depois levante o túnel. Se uma política gerenciada impedir essa ordem, siga o processo documentado da operadora ou do administrador.
As restrições da operadora são a outra variável: alguns caminhos transportam apenas certos protocolos, outros traduzem endereços de forma agressiva e outros tratam uma família de endereços de maneira diferente da outra. A comparação reduz a falha ao caminho sem identificar qual mecanismo é o responsável.
A transferência não é o mesmo que reconectar
Depois que cada rede funciona sozinha, observe uma transferência real. O cliente pode detectar a mudança e reconectar, ou manter uma sessão que agora está morta. Aplicações já em uso se recuperam de forma diferente das que são abertas depois da troca, então um ícone de túnel persistente prova pouco. Teste a aplicação que realmente importa para você durante a transição e anote se ela se recupera sem intervenção manual.
Se o túnel falha só depois de ficar inativo, um sinal de manutenção pode resolver um caso de estado de NAT. Não conserta um sinal fraco e não corrige toda transferência. Distinga inatividade de movimento antes de mudar configurações.
Anote a rede, a etapa da falha e o comportamento durante uma transferência. Esses três separam um problema de caminho de um problema de cliente.