OpenVPN non conecta na WiFi dun hotel? Proba TCP 443

Abre o cliente, preme Conectar e le a liña de estado en lugar do diálogo que vén despois. Un perfil que queda parado en Conectando ou Agardando polo servidor tras unha rede de hotel, campus ou móbil normalmente perdeu o seu transporte nalgún punto do camiño, non as súas credenciais. O seguinte paso útil é saber que transporta esa rede antes de tocar o servidor. Non cambies nada ata que o mesmo perfil funcione noutro sitio.

Proba primeiro desde un punto de acceso do teléfono. Se o túnel levanta alí, o servidor, o certificado e a conta están ben, e a única variable que queda é a rede que tes diante.

Empeza no cliente: le a liña de estado

A liña de estado di en que etapa fallou. Un cliente atascado en Conectando aínda está resolvendo o host ou abrindo o socket exterior; un que chega a Agardando polo servidor ten camiño pero non ten resposta; un que autentica e despois cae ten un problema completamente distinto. O rexistro do cliente e os propios campos remote e proto do perfil amosan o que o cliente intenta facer, e --verb 4 nun cliente de liña de ordes imprime o mesmo detalle. Comparar iso coa rede que tes diante é o que converte o 'a VPN está bloqueada' nunha afirmación concreta.

Despois sonda a rede coas ferramentas que xa tes. nc -vzu 203.0.113.10 1194 envía un datagrama UDP, curl -v telnet://203.0.113.10:443 informa se se completa unha aperta de mans TCP, e un navegador que carga unha páxina HTTPS só demostra que a saída 443 chega a ese único host. As sondas pequenas responden o que o cliente VPN non pode: que porto e que protocolo saen desta rede sequera.

Tres comportamentos de rede parécense desde o cliente e precisan respostas distintas. A saída 443 pode estar aberta, pode permitirse só un proxy, ou 443 pode reenviarse de forma transparente a unha caixa de inspección que non pode ler o que transporta. O primeiro arranxase co cambio de perfil de abaixo, o segundo cos axustes de proxy, e o terceiro pode completar unha aperta de mans e despois quedar parado cando o inspector decide que non lle gusta o fluxo. Saber cal dos tres tes diante é a diferenza entre un cambio de dez minutos e unha tarde reinstalando clientes.

Move o listener e o perfil xuntos

No servidor, pon o listener no que a rede permita: port 443 e proto tcp na configuración do servidor, despois reinicia o servizo e confirma o socket con ss -lntp. No cliente, o perfil ten que concordar, porque o transporte e o porto están fóra do túnel: proto tcp e port 443 no .ovpn, ou os campos correspondentes na pantalla de axustes da aplicación. Un perfil que aínda apunta a UDP 1194 falla exactamente igual que antes, e a tentación é culpar un firewall que xa está arranxado. Se o mesmo host tamén responde HTTPS en 443, os dous listeners non poden compartir ese enderezo e protocolo; dálle á VPN un segundo enderezo ou pon un demultiplexor diante.

Segue a primeira conexión con tcpdump -ni any port 443 nos dous extremos. Os paquetes que saen do cliente e nunca chegan significan que a rede filtra despois de todo, ou que o enderezo do perfil non é o que supoñes. Os paquetes que chegan sen resposta devólvente ao rexistro do servidor, onde unha falta de correspondencia de protocolo aparece de inmediato como un paquete descartado.

Cando só un proxy sae da rede

Algunhas redes de convidados non permiten nada agás un proxy HTTP, o que é unha restrición distinta dun porto pechado e descarta máis que OpenVPN. Os clientes que só falan PPTP, L2TP/IPsec ou IPsec espido non teñen forma de pasar por un, porque eses deseños esperan que o seu protocolo exterior chegue directamente ao servidor. OpenVPN si pode, con http-proxy proxy.example.net 8080 no perfil do cliente, sempre que o proxy permita o método CONNECT cara ao teu porto. Un proxy SOCKS é aínda máis doado, porque reenvía o fluxo sen importarlle o que leva dentro.

Onde o cliente non ten soporte de proxy, un túnel SSH sobre 443 adoita ser o que queda. Engade unha segunda capa, e o operador da rede pode ter unha opinión sobre iso, así que trátao como unha ponte para unha viaxe en vez de como unha arquitectura.

Ponlle prezo á alternativa antes de mantela

TCP dentro de TCP ten un custo coñecido. Cando a conexión exterior é TCP e a carga útil tamén é TCP, un segmento perdido provoca retransmisión nas dúas capas, e a conexión interior retrocede por unha perda que non pode ver. A navegación sobrevive a iso; as sesións interactivas e as chamadas sénteno. Mantén o listener TCP 443 como alternativa para as redes que o esixen, e deixa UDP como predeterminado para todo o que aínda o deixa pasar.

Rexistra a elección no nome do perfil e nas notas de asistencia: que porto, que protocolo e que rede o motivou. Despois pregunta ao administrador da rede se ese porto segue aberto tras a próxima renovación de equipamento, porque unha alternativa que desaparece en silencio é peor que non ter ningunha.