OpenVPN al 443 encara bloquejat? Comprova què inspecciona la xarxa

El túnel es connecta des d’una línia domèstica i s’encalla en una xarxa d’hotel o d’oficina, i moure el servidor al port 443 no va canviar res. Aquest resultat és prou comú per tenir una forma: el port era la part fàcil, i la resta de la decisió pertany a tot el que hi ha entre el client i el servidor. Dues preguntes resolen la majoria dels casos, i cap de les dues no és sobre xifradors. La xarxa accepta un intercanvi TLS cap a aquesta adreça, i el client manté una ruta cap al seu propi embolcall mentre el túnel és actiu?

L’intercanvi revela més que el número

Un escoltador VPN natiu al TCP 443 parla el seu propi protocol des del primer paquet. Un ClientHello té un camp de versió, un valor aleatori i una llista d’extensions, i un dispositiu que llegeix uns quants centenars de bytes pot distingir la diferència sense desxifrar res. Els números de port són barats de satisfer, i la forma del protocol és el que el filtre comprova realment. Les regles també se solen escriure per protocol, així que una política que inspecciona TLS no diu res sobre UDP.

Un proxy transparent que exigeix una sessió TLS vàlida talla la connexió durant la configuració, sovint després que l’intercanvi TCP s’hagi completat. Aquest detall importa més endavant, perquè vol dir que el registre del client s’atura després d’establir el sòcol.

Embolcallar el flux crea dos punts de fallada

Un embolcall TLS com stunnel restaura la forma esperada: el client es connecta a un escoltador local, l’embolcall obre una sessió TLS real cap al servidor al 443, i un segon embolcall al servidor reenvia els bytes desxifrats al dimoni VPN. La sessió exterior ara sembla qualsevol altra connexió HTTPS. El dimoni VPN del servidor hauria d’escoltar només al loopback, perquè res fora de l’embolcall no hi ha d’arribar.

Tres coses separades han d’encaixar per a aquest disseny. El perfil del client apunta a l’escoltador local, el certificat del servidor coincideix amb el nom que el client verifica, i el reenviament del costat del servidor apunta al port que el dimoni fa servir de debò. Equivoqueu-vos en qualsevol d’elles i la connexió mor abans d’arribar a la capa VPN. Llavors una discrepància de certificat apareix com un error d’embolcall i no com un error VPN, i per això val la pena llegir els dos registres costat a costat.

La ruta cap a l’embolcall és el parany

Quan el túnel s’aixeca, la ruta per defecte hi apunta, i la sessió TLS exterior necessita un camí que no entri al túnel que transporta. Un client VPN normal protegeix l’adreça que marca; un client embolcallat marca el seu propi loopback, així que l’adreça de destinació de l’embolcall és invisible per a aquesta protecció.

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

Les adreces exactes les heu d’omplir vosaltres, i la ruta ha d’existir durant tota la vida de la connexió, no només en arrencar. Un petit script embolcall que afegeix la ruta abans del client i la treu després és més fiable que una ordre recordada.

A Android, l’equivalent d’aquesta excepció és un paràmetre per aplicació: excloeu l’aplicació embolcall del túnel perquè el seu propi trànsit surti per la connexió mòbil. Sense l’exclusió, l’embolcall es dirigeix dins del túnel que intenta construir, i el bucle de reconnexió sembla un problema del servidor.

Llegiu el temps abans de canviar res

Una sessió que mor després del mateix interval cada vegada és una signatura de política i no una fallada criptogràfica, i els límits de flux de llarga durada produeixen exactament aquest patró. Una connexió que es reinicia immediatament després de l’intercanvi suggereix un proxy que no ha acceptat la cadena de certificats.

Compareu l’emissor del certificat d’un lloc HTTPS normal des de les dues xarxes. Si l’emissor difereix a la xarxa restringida, alguna cosa està acabant el TLS al mig, i cap embolcall sobreviurà a aquesta intercepció sense canvis. La mateixa comparació us diu si el bloc apunta al nom del vostre servidor o a cada sessió TLS en aquesta adreça.

Escriviu el comportament observat: quant va durar la sessió, si el sòcol es va obrir, si l’embolcall va registrar un intercanvi. Cadascun d’aquests punts estreta la prova següent.

Proveu una variable alhora

Comproveu primer UDP, perquè algunes xarxes el descarten del tot i una fallada UDP no diu res sobre el 443. Després proveu TCP 443 sense l’embolcall, i després l’embolcall al 443. Llegiu el registre del client a cada pas i atureu-vos tan bon punt el comportament canviï.

Canvieu un element per intent. Un port nou, un embolcall nou i un xifrador nou a la mateixa tongada us deixen sense poder dir quin dels tres ha importat.