Por que un perfil de OpenVPN funciona na casa pero falla nun hotel

O Wi-Fi da oficina e unha habitación de hotel poden darlle ao mesmo portátil dúas redes moi distintas, e o perfil de entre medias non ten nin idea. O que funciona na casa supón unha ligazón ascendente permisiva, unha resolución de nomes que funcione e unha subrede local que non choque con nada do que transporta o túnel. Cada unha desas suposicións pode fallar por separado.

A forma útil de depurar isto é tratar a rede como catro feitos separados e logo probalos en orde. Adiviñar o perfil primeiro adoita producir un cambio que non arranxa nada e escurece as probas.

Catro feitos de rede cambian entre localizacións

O primeiro feito é se a rede local te deixa saír sequera. Un portal cativo admite un dispositivo nunha páxina de inicio de sesión e bloquea todo o demais ata que esa páxina se completa, o que significa que o túnel non pode arrincar por correcto que sexa o perfil.

O segundo é a resolución de nomes. Un portal que intercepta DNS responde a cada consulta coa súa propia dirección, de modo que o nome de host da VPN se resolve ao portal e o cliente tenta construír un túnel cara a unha páxina web.

O terceiro é o filtrado de transporte. As redes que queren permitir só a navegación deixan pasar TCP 443 cara a destinos arbitrarios e descartan case todo o demais, incluído UDP.

O cuarto é o direccionamento. A subrede local pode superpoñerse cunha rede detrás do túnel, ou a ligazón ascendente pode non ofrecer ningunha ruta IPv4 utilizábel.

Resolución de nomes e portal cativo

Substitúa o nome de host do perfil pola dirección numérica do servidor e ténteo de novo. Se a IP conecta e o nome non, a culpa é da resolución, e o perfil en si está ben.

Abra un navegador e tente unha páxina HTTP normal antes de tocar a VPN. Unha redirección a unha páxina de inicio de sesión significa que o portal segue pendente; compléteo e volva conectar. Moitos hoteis tamén fan caducar a sesión ao cabo de poucas horas, o que parece unha desconexión a mediodía máis que un problema de inicio de sesión.

Se a dirección numérica tamén falla, a resolución non é a explicación, así que pase ao transporte. Garde a dirección que probou, porque lle di á seguinte comprobación se os paquetes saíron sequera da máquina.

Filtrado de transporte: primeiro UDP, TCP 443 como alternativa

Un fluxo de OpenVPN sobre UDP 1194 non se parece a nada que recoñeza un cortalumes de hotel, así que se descarta sen erro. O cliente reintenta ata que expira o seu tempo de espera, e o usuario ve unha conexión que nunca se establece en lugar dun rexeitamento. Os cortalumes que se comportan así raramente rexistran o descarte nun lugar visible. A ausencia dun rexeitamento é en si mesma a pista.

TCP 443 é a alternativa fiable porque a rede non pode distinguilo dun HTTPS normal. Use o perfil TCP do operador cando exista, xa que o servidor tamén debe escoitar nese transporte e porto; cambiar só o cliente produce outro tipo de fallo. Se non existe ningún perfil TCP, pregunte ao operador en lugar de inventar un editando o porto. O lado do servidor ten que aceptar, e un desaxuste volve parecer un problema de cortalumes.

Espere un custo de rendemento. TCP dentro de TCP amplifica as retransmisións nunha ligazón con perdas, así que un túnel TCP que funciona pode seguir sentirse lento nunha rede de hotel congestionada. É un intercambio por alcanzabilidade, non un fallo que perseguir.

Colisións de direccións e ligazóns sen IPv4

Un túnel pode establecerse e non transportar nada. Cando a LAN local e unha rede remota comparten un prefixo como 192.168.1.0/24, o cliente considera que o host remoto está conectado directamente e envía o paquete á ligazón local en lugar do túnel. O síntoma é unha conexión correcta cunha subrede inalcanzable, que se le facilmente como un problema de ruta no lado do servidor.

A solución permanente é mover a LAN remota a un rango privado pouco habitual. Escoller un rango que ninguén use na casa, como 10.42.0.0/24, evita o problema para cada localización futura en vez de para unha. O apaño local é evitar ese hotel, punto de acceso ou router, que non é ningunha solución.

As ligazóns móbiles engaden dúas variantes. O NAT de nivel de operador significa que as conexións entrantes non chegan, o que importa se aloxas un servidor pero non para un cliente saínte. Un APN configurado só con IPv6 e tradución NAT64 pode facer fallar un cliente que esixe unha ruta IPv4 real, e o remedio habitual é cambiar o protocolo do APN a IPv4 ou a pila dobre.

Síntomas despois de que o túnel estea levantado

Un túnel que conecta e logo queda calado adoita ser un problema de keepalive ou de MTU, non un porto bloqueado. Unha conexión que cae tras un número fixo de minutos apunta a un temporizador de keepalive ou de renegociación. Configure o cliente para sondar o seu par e reiniciarse cando as respostas se deteñan, e probe un MTU de túnel menor se os ping funcionan mentres as transferencias grandes se atascan.

Antes de pedir axuda, anote tres cousas: a dirección que probou e se respondeu, o transporte e o porto que usou, e a subrede local da rede que fallou. Xuntas separan a resolución de nomes do filtrado de transporte e dunha colisión de direccións, que son as causas que sobreviven ao contacto coas probas.