VPN bloquejat en una xarxa només web? Treballeu per capes

Una xarxa de campus o d’hotel on el navegador funciona i cada túnel mor no és un problema, són quatre de sobreposats. El camí pot permetre només TCP 443, pot exigir un proxy autenticat, pot inspeccionar l’aplec de mans i pot simplement prohibir l’accés remot per política. Treballar-los per ordre us estalvia comprar un client nou per arreglar una regla de xarxa. El manual següent dura uns deu minuts i acaba amb una resposta escrita sobre quina capa us ha refusat.

Demostreu quina capa refusa la connexió

No comenceu pel client VPN. Comenceu amb una petició HTTPS senzilla al mateix host i llegiu les fases de temps, perquè la fase que falla us diu quin dispositiu és el responsable:

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

Cap resposta i cap temps connect vol dir que TCP no es va completar mai, així que hi ha un tallafoc, un requisit de proxy o una destinació equivocada. Un temps connect sense temps tls vol dir que alguna cosa del mig va acceptar la connexió i després va aturar l’aplec de mans, i així és com es veu un proxy inspector des del costat del client.

Ara inspeccioneu el certificat que realment rebeu. És la manera més ràpida d’esbrinar si parleu amb el servidor o amb una caixa intermèdia que ha tornat a signar la sessió:

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

Llegiu la línia de l’emissor. La vostra pròpia CA vol dir que heu arribat al servei; un emissor corporatiu o d’aparell vol dir que un filtre ha acabat la connexió i decideix què passa després. Enregistreu les dues sortides amb una marca de temps, perquè la mateixa prova una hora més tard a la xarxa de convidats pot donar una resposta diferent.

Un client conscient del proxy canvia el primer paquet, no la política

Si la xarxa exigeix CONNECT a través d’un proxy autenticat, cal dir-ho al client VPN, o intentarà obrir un sòcol a una adreça que no pot encaminar. Proveu el proxy per separat del client, perquè el fracàs tingui una sola explicació:

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

La primera ordre demostra que el proxy portarà la destinació. La segona demana al client que faci servir TCP al 443, l’únic transport que la majoria de camins només web deixaran passar. Si la primera ordre funciona i la segona encara falla, el proxy no és l’obstacle.

Alguns clients llegeixen el proxy del sistema operatiu en lloc d’una anul·lació, i alguns no llegeixen cap dels dos. Consulteu la documentació de l’aplicació abans de suposar que un paràmetre global s’aplica. Un client que resol el punt final amb un resolutor que el proxy no serveix també fallarà aquí, i per això un canvi de DNS pot semblar una solució quan només és un desviament.

Mireu també el patró de redirecció mentre hi sou. Una xarxa filtrada pot respondre al nom d’amfitrió de detecció d’un proveïdor amb alguna cosa pròpia, cosa que canvia quin perfil de proxy tria el client. No construïu cap procés al voltant d’aquesta raresa. Varia segons l’emplaçament, canvia sense avís i no és una cosa que pugueu suportar per a ningú altre.

El port 443 és abastable, no permès

Embolcallar un túnel en TLS al 443 resol l’abastabilitat i res més. Un filtre que comprova el port el deixarà passar; un filtre que pren l’empremta de l’aplec de mans no, i la salutació xifrada del client només amaga el nom del servidor quan tots dos costats la suporten. Feu la prova i esbrineu darrere de quin tipus de filtre sou en lloc d’esperar-ho.

També hi ha un cost de rendiment que la gent descobreix més tard. Un transport fiable dins d’un transport fiable amplifica la pèrdua, perquè la pila interior retransmet segments que la pila exterior ja ha retransmès. En un enllaç net ningú no ho nota. En una xarxa sense fil de campus congestionada el túnel es torna inutilitzable just quan el necessiteu, i el gràfic sembla pèrdua de paquets tot i que no es descarta res a propòsit.

UDP sol ser la primera víctima, i val la pena confirmar-ho en lloc de deduir-ho. Si WireGuard o l’OpenVPN per defecte no completa mai l’aplec de mans mentre TCP 443 funciona, la xarxa descarta UDP, i cap regeneració de claus ho canviarà:

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

Una marca de temps d’aplec de mans buida al costat d’un company que ahir funcionava és la resposta d’UDP. Les dues consultes DNS responen una altra pregunta: si el resolutor local i un resolutor públic no coincideixen sobre l’adreça del punt final, us estan redirigint i l’argument del transport és l’equivocat.

Verifiqueu què va sortir realment de la màquina

Els registres del client descriuen què creu el client. Una captura descriu què va veure la xarxa, i la diferència entre les dues és on es resolen la majoria d’aquests 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'

Si veieu paquets SYN i cap SYN-ACK, el bloc és més amunt i el client és innocent. Si veieu un aplec de mans complet cap a una adreça que no és la del servidor, parleu amb un proxy o un interceptor. Si no veieu res de res, comproveu que heu capturat a la interfície correcta abans de concloure res.

La llista de sòcols atrapa un cas més subtil: un segon túnel que ja té la ruta per defecte. Dos clients que es barallen per la taula d’encaminament produeixen fallades intermitents que semblen exactament una xarxa bloquejada, i la captura mostrarà trànsit sortint per una interfície que no esperàveu.

Marxa enrere i la nota que val la pena guardar

Desfeu els canvis en l’ordre invers en què els heu fet. Desactiveu les variables de proxy, atureu el client que heu iniciat a mà i traieu qualsevol anul·lació de ruta o resolutor que hàgiu afegit:

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

Deixar un client iniciat a mà en marxa és com acaba un portàtil amb una xarxa trencada a la propera visita a l’oficina. Les variables de proxy deixades en un perfil d’intèrpret trenquen eines no relacionades setmanes després, i qui les depura no relacionarà els dos esdeveniments.

Després escriviu quatre línies: la xarxa, la marca de temps, la fase que va fallar i l’emissor que vau veure. Un camí que funciona en un campus i falla al següent és normal, i la persona següent ha de saber si la diferència era el proxy, el resolutor o el filtre. Si la resposta és que la xarxa prohibeix l’accés remot, atureu-vos aquí i demaneu a l’administrador la ruta suportada en lloc de portar una solució alternativa a una política que no heu llegit.