OpenVPN no 443 aínda bloqueado? Comproba que inspecciona a rede

O túnel conéctase desde unha liña doméstica e atasca nunha rede de hotel ou oficina, e mover o servidor ao porto 443 non cambiou nada. Ese resultado é abondo común para ter unha forma: o porto era a parte fácil, e o resto da decisión pertence a todo o que está entre o cliente e o servidor. Dúas preguntas resolven a maioría dos casos, e ningunha delas trata de cifrados. Acepta a rede un saúdo TLS cara a ese enderezo, e mantén o cliente unha ruta cara ao seu propio envoltorio mentres o túnel está levantado?

O saúdo revela máis ca o número

Un escoitador VPN nativo en TCP 443 fala o seu propio protocolo desde o primeiro paquete. Un ClientHello ten un campo de versión, un valor aleatorio e unha lista de extensións, e un dispositivo que le uns centos de bytes pode notar a diferenza sen descifrar nada. Os números de porto son baratos de satisfacer, e a forma do protocolo é o que o filtro comproba de verdade. As regras tamén se escriben por protocolo, así que unha política que inspecciona TLS non di nada sobre UDP.

Un proxy transparente que esixe unha sesión TLS válida corta a conexión durante a configuración, a miúdo despois de que o saúdo TCP se complete. Ese detalle importa máis adiante, porque significa que o rexistro do cliente se detén tras establecerse o socket.

Envolver o fluxo crea dous puntos de fallo

Un envoltorio TLS como stunnel restaura a forma agardada: o cliente conéctase a un escoitador local, o envoltorio abre unha sesión TLS real cara ao servidor no 443, e un segundo envoltorio no servidor reenvía os bytes descifrados ao demo VPN. A sesión exterior agora parece calquera outra conexión HTTPS. O demo VPN do servidor debería escoitar só en loopback, porque nada fóra do envoltorio necesita alcanzalo.

Tres cousas separadas deben aliñarse para ese deseño. O perfil do cliente apunta ao escoitador local, o certificado do servidor coincide co nome que o cliente verifica, e o reenvío do lado do servidor apunta ao porto que o demo usa de verdade. Fallas calquera delas e a conexión morre antes de chegar á capa VPN. Entón unha discrepancia de certificado aparece como erro do envoltorio e non como erro de VPN, e por iso paga a pena ler ambos rexistros un ao lado do outro.

A ruta cara ao envoltorio é a trampa

Cando o túnel sobe, a ruta por defecto apunta cara a el, e a sesión TLS exterior necesita un camiño que non entre no túnel que transporta. Un cliente VPN normal protexe o enderezo ao que marca; un cliente envolto marca o seu propio loopback, así que o enderezo de destino do envoltorio é invisible para esa protección.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Os enderezos exactos cómprechos ti, e a ruta debe existir durante toda a vida da conexión, non só ao arrincar. Un pequeno script envoltorio que engade a ruta antes do cliente e a quita despois é máis fiable que un comando recordado.

En Android, o equivalente desa excepción é un axuste por aplicación: exclúe a aplicación envoltorio do túnel para que o seu propio tráfico saia pola conexión móbil. Sen a exclusión, o envoltorio enrútase dentro do túnel que intenta construír, e o bucle de reconexión parece un problema do servidor.

Le os tempos antes de cambiar nada

Unha sesión que morre tras o mesmo intervalo cada vez é unha sinatura de política e non un fallo criptográfico, e os límites de fluxo de longa duración producen exactamente ese patrón. Unha conexión que se reinicia xusto despois do saúdo suxire un proxy ao que non lle gustou a cadea de certificados.

Compara o emisor do certificado dun sitio HTTPS normal desde as dúas redes. Se o emisor difire na rede restrinxida, algo está rematando TLS no medio, e ningún envoltorio sobrevivirá a esa interceptación sen cambios. A mesma comparación díche se o bloqueo apunta ao nome do teu servidor ou a cada sesión TLS nese enderezo.

Anota o comportamento observado: canto durou a sesión, se o socket se abriu, se o envoltorio rexistrou un saúdo. Cada un deses datos estreita a proba seguinte.

Proba unha variable cada vez

Comproba primeiro UDP, porque algunhas redes descártano por completo e un fallo de UDP non di nada sobre o 443. Despois proba TCP 443 sen o envoltorio, e logo o envoltorio no 443. Le o rexistro do cliente en cada paso e detente en canto cambie o comportamento.

Cambia un elemento por intento. Un porto novo, un envoltorio novo e un cifrado novo na mesma quenda déixanche sen poder dicir cal dos tres importou.