La VPN es connecta a casa però pateix temps d'espera al Wi-Fi de l'hotel

El portàtil s'uneix al Wi-Fi de casa, el client es connecta en tres segons, i el mateix perfil falla a l'hotel una hora després. No s'ha actualitzat res entremig. Recórrer això amb un client davant teu tracta sobretot de saber quin error pertany a quina etapa, perquè la informació útil és al codi que imprimeix el client, no en el fet que hagi fallat. Fes els quatre passos següents en ordre i sabràs si et va rebutjar un nom, un paquet, un port o una política.

Llegeix el codi d'error com una etapa, no com un veredicte

El client arriba a tres fites separades abans que existeixi un túnel. Resol el nom del servidor, obté una resposta d'alguna cosa a la xarxa i negocia una associació de seguretat. Cada fita té el seu propi missatge de fallada, i Windows en particular és generós amb codis diferents un cop saps a quina etapa pertanyen.

Dos d'aquests codis volen dir que la xarxa és innocent. Un 789 vol dir que els paquets fluïen i que els dos extrems no es posaven d'acord sobre la criptografia, que és un problema de configuració que pots arreglar a casa. Un 868 vol dir que cap paquet no havia de sortir, així que el disseny del túnel és irrellevant fins que es resolgui el nom. Classificar el codi a l'etapa correcta estalvia més temps que qualsevol captura, perquè et diu quin dels tres passos següents pots saltar-te.

Sigues prudent com cal si el client no és Windows. Els clients de tercers ho reduïxen gairebé tot a "connexió fallida", i per això els dos passos següents no es refien del missatge en absolut.

Comprova el nom abans de culpar el túnel

Les xarxes d'hotels i aeroports intercepten el DNS constantment, i un resolutor que respon amb una adreça de portal produeix una fallada que sembla exactament un servidor mort. Compara què diu el resolutor local amb què diu un resolutor públic:

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

Si les dues respostes difereixen, t'estan redirigint i la resta del diagnòstic és inútil fins que això es resolgui. Una adreça de portal, en particular, acceptarà encantada la connexió TCP i després es quedarà encallada, i per això pot semblar un bloqueig de tallafocs quan proves amb un navegador.

Ara confirma que l'adreça que vols assolir és la que s'utilitza. Alguns clients desen la resolució anterior durant tota la vida del perfil, així que una reconnexió després del canvi de DNS encara va a l'adreça antiga. Tanca el client del tot abans de tornar a provar, en lloc de prémer desconnecta i connecta a la mateixa finestra.

Esbrina quin paquet exterior desapareix

El túnel té un flux exterior que pertany del tot al camí entre tu i el servidor, i és aquest flux el que els equips intermedis classifiquen i descarten. Captura'l al client i després compara una xarxa que funciona amb la que falla. A Windows la captura integrada ja n'hi ha prou per a una primera ullada:

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

El que vols veure és si els teus paquets surten, i si torna alguna cosa. Paquets enfora sense res a canvi vol dir que el camí o l'extrem llunyà els descarta; si no en surt cap, el client no va arribar mai a enviar, cosa que apunta a la resolució de noms o a una política local de tallafocs.

Repeteix la mateixa prova amb un punt d'accés del mòbil. Aquesta és la comparació més informativa que tens a l'abast, perquè treu del camí cada caixa de l'hotel mentre manté idèntics el portàtil, el client i les credencials. Si el túnel s'aixeca al punt d'accés, deixa de mirar el servidor. Si també falla allà, tens un problema de client o de compte que la xarxa no causava mai.

Canvia un transport i torna a provar

Un cop saps que el flux exterior es descarta, la pregunta pràctica és quin flux permet la xarxa. La majoria de xarxes restringides permeten TCP 443 de sortida perquè no podrien funcionar d'altra manera, així que moure-hi l'escoltador és la resposta habitual. A OpenVPN això és un commutador del costat del client fins que es canvia el servidor:

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

Els clients IPsec tenen un control equivalent als seus propis panells de paràmetres, normalment descrit com a IPsec sobre TCP o travessa de NAT. Canviar-lo també és un diagnòstic: si el túnel s'aixeca sobre TCP i mor sobre UDP, has demostrat que la xarxa filtra UDP, i també has trobat el paràmetre que necessitaràs cada vegada que visitis aquest lloc.

Resisteix la temptació de desactivar funcions del router al primer intent. Apagar la inspecció amb estat o la protecció contra inundacions en una xarxa d'hotel no és a la teva mà, i al teu equip canvia una protecció real per un sol portàtil. Anota quin paràmetre va canviar el resultat, després torna'l a posar i busca un transport que la xarxa ja permeti.

Verifica el mateix perfil a la segona xarxa

Abans de tancar el tiquet, demostra que el canvi va sobreviure a sortir de l'edifici. Torna a connectar-te a la xarxa original amb els paràmetres originals, captura els primers trenta segons i confirma que el client arriba al mateix estat que al punt d'accés:

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

La distinció que revela l'última ordre val la pena de conservar: el perfil pot informar d'un túnel connectat mentre l'encaminament de dins és incorrecte, i això produeix "la VPN està activa però no funciona res", que és un altre article. Si el tipus de túnel va canviar després de la teva edició, el perfil no és el que vas provar.

Després escriu la troballa on la mirarà la persona següent. "El perfil corporatiu necessita TCP 443 en aquest lloc; l'hotel filtra UDP 500" és una frase sobre la qual un col·lega pot actuar. "La VPN va malament als hotels" no ho és, i garanteix que la mateixa hora es tornarà a gastar el mes que ve.