A VPN conecta na casa pero dá tempo de espera no Wi-Fi do hotel

O portátil únese ao Wi-Fi da casa, o cliente conecta en tres segundos, e o mesmo perfil falla no hotel unha hora despois. Entre medias non se actualizou nada. Percorrer isto cun cliente diante consiste sobre todo en saber que erro pertence a que etapa, porque a información útil está no código que imprime o cliente, non no feito de que fallase. Segue os catro pasos de abaixo en orde e saberás se che rexeitou un nome, un paquete, un porto ou unha política.

Le o código de erro como unha etapa, non como un veredicto

O cliente alcanza tres fitos separados antes de que exista un túnel. Resolve o nome do servidor, obtén unha resposta de algo na rede e negocia unha asociación de seguridade. Cada fito ten a súa propia mensaxe de fallo, e Windows en particular é xeneroso con códigos distintos unha vez sabes a que etapa pertencen.

Dous deses códigos significan que a rede é inocente. Un 789 significa que os paquetes fluían e os dous extremos non se puxeron de acordo sobre a criptografía, que é un problema de configuración que podes arranxar na casa. Un 868 significa que ningún paquete necesitou saír nunca, así que o deseño do túnel é irrelevante ata que se resolva o nome. Clasificar o código na etapa correcta aforra máis tempo que calquera captura, porque che di cal dos tres pasos seguintes podes saltar.

Sé prudente como corresponde se o cliente non é Windows. Os clientes de terceiros reducen case todo isto a "conexión fallida", e por iso os dous pasos seguintes non dependen en absoluto da mensaxe.

Comproba o nome antes de culpar o túnel

As redes de hoteis e aeroportos interceptan DNS constantemente, e un resolutor que responde cun enderezo de portal produce un fallo que parece exactamente un servidor morto. Compara o que di o resolutor local co que di un público:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Se as dúas respostas difiren, estanche redirixindo e o resto do diagnóstico é inútil ata que iso se resolva. Un enderezo de portal en particular aceptará encantado a conexión TCP e despois quedará colgado, e por iso pode parecer un bloqueo de devasa cando probas cun navegador.

Agora confirma que o enderezo ao que queres chegar é o que se está usando. Algúns clientes gardan na caché a resolución anterior durante toda a vida do perfil, así que unha reconexión despois do cambio de DNS segue indo ao enderezo antigo. Pecha o cliente por completo antes de volver probar, en lugar de premer desconectar e conectar na mesma xanela.

Averigua que paquete exterior desaparece

O túnel ten un fluxo exterior que pertence por completo ao camiño entre ti e o servidor, e é ese fluxo o que os equipos intermedios clasifican e descartan. Captúrao no cliente e despois compara unha rede que funciona coa que falla. En Windows a captura integrada abonda para un primeiro vistazo:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

O que queres ver é se os teus paquetes saen sequera e se volve algo. Paquetes cara a fóra sen nada de volta significa que o camiño ou o extremo afastado os descarta; que non saia nada en absoluto significa que o cliente nunca chegou a enviar, o que apunta á resolución de nomes ou a unha política local de devasa.

Repite a mesma proba nun punto de acceso do móbil. É a comparación máis informativa da que dispós, porque quita do camiño cada caixa do hotel mentres mantén idénticos o portátil, o cliente e as credenciais. Se o túnel sobe no punto de acceso, deixa de mirar o servidor. Se tamén falla alí, tes un problema de cliente ou de conta que a rede nunca estaba causando.

Cambia un transporte e volve probar

Unha vez sabes que o fluxo exterior se descarta, a pregunta práctica é que fluxo permite a rede. A maioría das redes restrinxidas permiten TCP 443 saínte porque non poderían funcionar doutro xeito, así que mover o escoitador alí é a resposta habitual. En OpenVPN iso é un interruptor do lado do cliente ata que se cambie o servidor:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Os clientes IPsec teñen un control equivalente nos seus propios paneis de axustes, normalmente descrito como IPsec sobre TCP ou atravesar NAT. Cambialo tamén é un diagnóstico: se o túnel sobe sobre TCP e morre sobre UDP, demostraches que a rede filtra UDP, e tamén atopaches o axuste que necesitarás cada vez que visites ese sitio.

Resiste a tentación de desactivar funcións do router ao primeiro intento. Apagar a inspección con estado ou a protección contra inundacións nunha rede de hotel non está ao teu alcance de todos os xeitos, e no teu propio equipo cambia unha protección real por un só portátil. Anota que axuste cambiou o resultado, despois volve poñelo e busca un transporte que a rede xa permita.

Verifica o mesmo perfil na segunda rede

Antes de pechar o tícket, demostra que o cambio sobreviviu a saír do edificio. Reconecta na rede orixinal cos axustes orixinais, captura os primeiros trinta segundos e confirma que o cliente alcanza o mesmo estado que alcanzou no punto de acceso:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

A distinción que revela o último comando merece conservarse: o perfil pode informar dun túnel conectado mentres o encamiñamento de dentro é incorrecto, e iso produce "a VPN está activa pero non funciona nada", que é outro artigo. Se o tipo de túnel cambiou despois da túa edición, o perfil non é o que probaches.

Despois escribe o achado onde mirará a seguinte persoa. "O perfil corporativo necesita TCP 443 neste sitio; o hotel filtra UDP 500" é unha frase sobre a que un colega pode actuar. "A VPN vai mal nos hoteis" non o é, e garante que a mesma hora se volva gastar o mes que vén.