Per què un perfil OpenVPN funciona a casa però falla en un hotel

El Wi-Fi de l'oficina i una habitació d'hotel poden donar al mateix portàtil dues xarxes molt diferents, i el perfil que hi ha entremig no en té ni idea. El que funciona a casa pressuposa un enllaç ascendent permissiu, una resolució de noms que funcioni i una subxarxa local que no xoqui amb res del que porta el túnel. Cadascuna d'aquestes suposicions pot fallar per separat.

La manera útil de depurar-ho és tractar la xarxa com quatre fets separats i després provar-los en ordre. Endevinar el perfil primer sol produir un canvi que no arregla res i amaga les proves.

Quatre fets de xarxa canvien entre ubicacions

El primer fet és si la xarxa local et deixa sortir, per començar. Un portal captiu admet un dispositiu en una pàgina d'inici de sessió i bloqueja tota la resta fins que aquella pàgina s'hagi completat, cosa que vol dir que el túnel no pot arrencar per correcte que sigui el perfil.

El segon és la resolució de noms. Un portal que intercepta DNS respon cada consulta amb la seva pròpia adreça, de manera que el nom d'amfitrió de la VPN es resol al portal i el client intenta construir un túnel cap a una pàgina web.

El tercer és el filtratge de transport. Les xarxes que volen permetre només la navegació deixen passar TCP 443 cap a destinacions arbitràries i descarten gairebé tota la resta, inclòs UDP.

El quart és l'adreçament. La subxarxa local pot superposar-se amb una xarxa darrere del túnel, o bé l'enllaç ascendent pot no oferir cap camí IPv4 utilitzable.

Resolució de noms i portal captiu

Substituïu el nom d'amfitrió del perfil per l'adreça numèrica del servidor i torneu-ho a provar. Si l'IP connecta i el nom no, la culpa és de la resolució, i el perfil mateix està bé.

Obriu un navegador i proveu una pàgina HTTP normal abans de tocar la VPN. Una redirecció a una pàgina d'inici de sessió vol dir que el portal encara està pendent; completeu-lo i torneu a connectar. Molts hotels també fan caducar la sessió al cap d'unes hores, cosa que sembla una desconnexió a mitja tarda més que no pas un problema d'inici de sessió.

Si l'adreça numèrica també falla, la resolució no és l'explicació, així que passeu al transport. Guardeu l'adreça que heu provat, perquè diu a la propera comprovació si els paquets han sortit de la màquina.

Filtratge de transport: primer UDP, TCP 443 com a alternativa

Un flux OpenVPN per UDP 1194 no s'assembla a res que un tallafoc d'hotel reconegui, així que es descarta sense error. El client reintenta fins que el seu temps d'espera expira, i l'usuari veu una connexió que mai s'estableix en lloc d'un refús. Els tallafocs que es comporten així poques vegades registren el descart en un lloc visible. L'absència d'un refús és ella mateixa la pista.

TCP 443 és l'alternativa fiable perquè la xarxa no el pot distingir d'un HTTPS normal. Feu servir el perfil TCP de l'operador quan n'hi hagi, ja que el servidor també ha d'escoltar en aquell transport i port; canviar només el client produeix un altre tipus de fallada. Si no hi ha cap perfil TCP, pregunteu a l'operador en lloc d'inventar-ne un editant el port. El costat del servidor ha de dir que sí, i un desajust torna a semblar un problema de tallafoc.

Espereu un cost de rendiment. TCP dins de TCP amplifica les retransmissions en un enllaç amb pèrdues, així que un túnel TCP que funciona pot semblar lent en una xarxa d'hotel congestionada. És un intercanvi per arribar-hi, no una fallada que calgui perseguir.

Col·lisions d'adreces i enllaços sense IPv4

Un túnel es pot establir i no portar res. Quan la LAN local i una xarxa remota comparteixen un prefix com 192.168.1.0/24, el client considera l'amfitrió remot directament connectat i envia el paquet a l'enllaç local en lloc del túnel. El símptoma és una connexió correcta amb una subxarxa inabastable, que es llegeix fàcilment com un problema de ruta al costat del servidor.

La solució permanent és moure la LAN remota a un rang privat poc habitual. Triar un rang que ningú no faci servir a casa, com 10.42.0.0/24, evita el problema per a cada ubicació futura en lloc d'una de sola. La solució local és evitar aquell hotel, punt d'accés o router, que no és cap solució.

Els enllaços mòbils afegeixen dues variants. El NAT de nivell d'operador fa que les connexions entrants no arribin, cosa que importa si hostatges un servidor però no per a un client de sortida. Un APN configurat només amb IPv6 i traducció NAT64 pot fer fallar un client que exigeix un camí IPv4 real, i el remei habitual és canviar el protocol de l'APN a IPv4 o a doble pila.

Símptomes després que el túnel estigui aixecat

Un túnel que es connecta i després queda en silenci sol ser un problema de keepalive o d'MTU, no un port bloquejat. Una connexió que cau al cap d'un nombre fix de minuts apunta a un temporitzador de keepalive o de renegociació. Configureu el client perquè sondegi el seu parell i reiniciï quan les respostes s'aturin, i proveu un MTU de túnel més petit si els ping funcionen mentre les transferències grans s'encallen.

Abans de demanar ajuda, apunteu tres coses: l'adreça que heu provat i si ha respost, el transport i el port que heu fet servir, i la subxarxa local de la xarxa que ha fallat. Juntes separen la resolució de noms del filtratge de transport i de la col·lisió d'adreces, que són les causes que sobreviuen al contacte amb les proves.