VPN bloqueada nunha rede só web? Traballa as capas

Unha rede de campus ou hotel onde o navegador funciona e cada túnel morre non é un problema, son catro apilados. A ruta pode permitir só TCP 443, pode esixir un proxy autenticado, pode inspeccionar o saúdo e pode simplemente prohibir o acceso remoto por política. Traballalos en orde evita que compres un cliente novo para arranxar unha regra de rede. O manual seguinte dura uns dez minutos e remata cunha resposta escrita sobre que capa che rexeitou.

Demostra que capa rexeita a conexión

Non comeces polo cliente VPN. Comeza cunha petición HTTPS simple ao mesmo host e le as fases de tempo, porque a fase que falla di que dispositivo é o responsable:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Sen resposta e sen tempo connect significa que TCP nunca se completou, así que hai un cortafocos, un requisito de proxy ou un destino equivocado. Un tempo connect sen tempo tls significa que algo no medio aceptou a conexión e despois detivo o saúdo, e así se ve un proxy inspector desde o lado do cliente.

Agora inspecciona o certificado que recibes de verdade. É a forma máis rápida de saber se falas co servidor ou cunha caixa intermedia que volveu asinar a sesión:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Le a liña do emisor. A túa propia CA significa que chegaches ao servizo; un emisor corporativo ou de dispositivo significa que un filtro rematou a conexión e decide que pasa despois. Rexistra ambas saídas cunha marca de tempo, porque a mesma proba unha hora despois na rede de convidados pode dar outra resposta.

Un cliente consciente do proxy cambia o primeiro paquete, non a política

Se a rede esixe CONNECT a través dun proxy autenticado, hai que dicirllo ao cliente VPN, ou tentará abrir un socket a un enderezo que non pode encamiñar. Proba o proxy por separado do cliente, para que un fallo teña unha soa explicación:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

O primeiro comando demostra que o proxy levará o destino. O segundo pide ao cliente usar TCP no 443, o único transporte que a maioría de rutas só web reenviarán. Se o primeiro comando funciona e o segundo segue fallando, o proxy non é o obstáculo.

Algúns clientes len o proxy do sistema operativo en lugar dunha anulación, e algúns non len ningún. Consulta a documentación da aplicación antes de supor que se aplica un axuste global. Un cliente que resolve o extremo cun resolvedor que o proxy non serve tamén fallará aquí, e por iso un cambio de DNS pode parecer unha solución cando só é un desvío.

Fíxate tamén no patrón de redirección mentres estás niso. Unha rede filtrada pode responder ao nome de detección dun provedor con algo propio, o que cambia que perfil de proxy escolle o cliente. Non constrúas un proceso arredor desa rareza. Varía por sitio, cambia sen aviso e non é algo que poidas soportar para ninguén máis.

O porto 443 é alcanzable, non permitido

Envolver un túnel en TLS sobre o 443 resolve a alcanzabilidade e nada máis. Un filtro que comproba o porto deixarao pasar; un filtro que toma a pegada do saúdo non, e o saúdo cifrado do cliente só oculta o nome do servidor cando ambos extremos o admiten. Executa a proba e descubre tras que tipo de filtro estás en lugar de esperar.

Tamén hai un custo de rendemento que a xente descobre despois. Un transporte fiable dentro doutro transporte fiable amplifica a perda, porque a pila interior retransmite segmentos que a pila exterior xa retransmitiu. Nun enlace limpo ninguén o nota. Nunha rede sen fíos de campus congestionada o túnel vólvese inutilizable xusto cando o necesitas, e o gráfico parece perda de paquetes aínda que nada se descarta a propósito.

UDP adoita ser a primeira vítima, e paga a pena confirmalo en lugar de deducilo. Se WireGuard ou o OpenVPN por defecto nunca completa un saúdo mentres TCP 443 funciona, a rede está a descartar UDP, e ningunha rexeneración de claves o cambiará:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Unha marca de tempo de saúdo baleira xunto a un par que onte funcionaba é a resposta de UDP. As dúas consultas DNS responden outra pregunta: se o resolvedor local e un público non coinciden sobre o enderezo do extremo, estanche redirixindo e o argumento do transporte é o equivocado.

Verifica que saíu realmente da máquina

Os rexistros do cliente describen que cre o cliente. Unha captura describe que viu a rede, e a diferenza entre ambas é onde se resolven a maioría destes casos:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Se ves paquetes SYN e ningún SYN-ACK, o bloqueo está augas arriba e o cliente é inocente. Se ves un saúdo completado cara a un enderezo que non é o do servidor, falas cun proxy ou un interceptor. Se non ves nada, comproba que capturouches na interface correcta antes de concluír nada.

A lista de sockets atrapa un caso máis sutil: un segundo túnel que xa ten a ruta por defecto. Dous clientes loitando pola táboa de rutas producen fallos intermitentes que parecen exactamente unha rede bloqueada, e a captura mostrará tráfico saíndo por unha interface que non esperabas.

Marcha atrás e a nota que paga a pena gardar

Desfai os cambios na orde inversa á que os fixeches. Quita as variables de proxy, detén o cliente que iniciaste a man e elimina calquera anulación de ruta ou resolvedor que engadiches:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Deixar un cliente iniciado a man en marcha é como un portátil acaba cunha rede rota na seguinte visita á oficina. As variables de proxy deixadas nun perfil de shell rompen ferramentas non relacionadas semanas despois, e quen as depura non relacionará os dous sucesos.

Despois escribe catro liñas: a rede, a marca de tempo, a fase que fallou e o emisor que viu. Unha ruta que funciona nun campus e falla no seguinte é normal, e a seguinte persoa necesita saber se a diferenza foi o proxy, o resolvedor ou o filtro. Se a resposta é que a rede prohibe o acceso remoto, para aí e pide ao administrador a ruta soportada en lugar de levar un rodeo a unha política que non liches.