VPN geblokkeerd op een netwerk met alleen web? Werk de lagen af

Een campus- of hotelnetwerk waar de browser werkt en elke tunnel sterft is niet één probleem, het zijn er vier op elkaar. Het pad staat misschien alleen TCP 443 toe, eist een geauthenticeerde proxy, inspecteert de handshake of verbiedt eenvoudigweg remote toegang per beleid. Ze in volgorde aanpakken voorkomt dat je een nieuwe client koopt om een netwerkregel te repareren. De runbook hieronder duurt ongeveer tien minuten en eindigt met een schriftelijk antwoord over welke laag je heeft geweigerd.

Bewijs welke laag de verbinding weigert

Begin niet bij de VPN-client. Begin met een gewoon HTTPS-verzoek naar dezelfde host en lees de timingfasen, want de fase die faalt vertelt welk apparaat verantwoordelijk is:

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

Geen antwoord en geen connect-tijd betekent dat TCP nooit voltooid is, dus een firewall, een proxy-eis of een verkeerde bestemming speelt mee. Een connect-tijd zonder tls-tijd betekent dat iets in het midden de verbinding accepteerde en daarna de handshake blokkeerde, en zo ziet een inspecterende proxy er vanaf de clientkant uit.

Bekijk nu het certificaat dat je werkelijk ontvangt. Dat is de snelste manier om erachter te komen of je met de server praat of met een tussenkast die de sessie opnieuw heeft ondertekend:

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

Lees de regel van de uitgever. Je eigen CA betekent dat je de dienst hebt bereikt; een bedrijfs- of apparaatuitgever betekent dat een filter de verbinding beëindigde en beslist wat er daarna gebeurt. Leg beide uitvoer vast met een tijdstempel, want dezelfde test een uur later op het gastnetwerk kan een ander antwoord geven.

Een proxybewuste client verandert het eerste pakket, niet het beleid

Als het netwerk CONNECT via een geauthenticeerde proxy vereist, moet de VPN-client dat weten, anders probeert hij een socket te openen naar een adres dat hij niet kan routeren. Test de proxy apart van de client, zodat een fout één verklaring heeft:

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

De eerste opdracht bewijst dat de proxy de bestemming draagt. De tweede vraagt de client TCP op 443 te gebruiken, het enige transport dat de meeste alleen-web-paden überhaupt doorlaten. Als de eerste slaagt en de tweede nog steeds faalt, is de proxy niet het obstakel.

Sommige clients lezen de proxy van het besturingssysteem in plaats van een overschrijving, en sommige lezen geen van beide. Controleer de documentatie van de applicatie voordat je aanneemt dat een systeembrede instelling geldt. Een client die het eindpunt oplost via een resolver die de proxy niet bedient, zal hier ook falen, en daarom kan een DNS-wijziging lijken op een oplossing wanneer het alleen een omweg is.

Let ook op het stuurpatroon. Een gefilterd netwerk kan op de detectiehostnaam van een leverancier antwoorden met iets van zichzelf, wat verandert welk proxyprofiel de client kiest. Bouw geen proces rond die eigenaardigheid. Die verschilt per locatie, verandert zonder kennisgeving en is niets wat je voor iemand anders kunt ondersteunen.

Poort 443 is bereikbaar, niet toegestaan

Een tunnel in TLS op 443 wikkelen lost bereikbaarheid op en niets anders. Een filter dat de poort controleert, laat hem door; een filter dat de handshake fingerprint, niet, en versleutelde client hello verbergt de servernaam alleen als beide uiteinden het ondersteunen. Voer de test uit en ontdek achter wat voor filter je zit in plaats van te hopen.

Er is ook een prestatiekosten die mensen later ontdekken. Een betrouwbaar transport binnen een betrouwbaar transport versterkt verlies, omdat de binnenste stack segmenten opnieuw verzendt die de buitenste al opnieuw heeft verzonden. Op een schone verbinding merkt niemand het. Op een overbelast campus-WLAN wordt de tunnel onbruikbaar precies wanneer je hem nodig hebt, en de grafiek lijkt op pakketverlies terwijl er niets met opzet wordt weggegooid.

UDP is meestal het eerste slachtoffer, en dat is het waard te bevestigen in plaats van te veronderstellen. Als WireGuard of standaard OpenVPN nooit een handshake voltooit terwijl TCP 443 werkt, laat het netwerk UDP vallen, en geen sleutelregeneratie zal dat veranderen:

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

Een lege handshake-tijdstempel naast een peer die gisteren werkte is het UDP-antwoord. De twee DNS-query's beantwoorden een andere vraag: als de lokale resolver en een publieke resolver het niet eens zijn over het eindpuntadres, word je gestuurd en is het transportargument het verkeerde.

Controleer wat de machine werkelijk verliet

Clientlogs beschrijven wat de client gelooft. Een capture beschrijft wat het netwerk zag, en het verschil tussen beide is waar de meeste van deze gevallen worden opgelost:

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

Als je SYN-pakketten ziet en geen SYN-ACK, zit de blokkade stroomopwaarts en is de client onschuldig. Als je een voltooide handshake naar een adres ziet dat niet van de server is, praat je met een proxy of een afvanger. Als je niets ziet, controleer dan of je op de juiste interface hebt opgenomen voordat je iets concludeert.

De socketlijst vangt een subtieler geval: een tweede tunnel die al de standaardroute vasthoudt. Twee clients die vechten om de routingtabel veroorzaken periodieke fouten die er precies uitzien als een geblokkeerd netwerk, en de capture zal verkeer tonen dat vertrekt via een interface die je niet verwachtte.

Terugdraaien, en de notitie die het waard is te bewaren

Draai de wijzigingen terug in de omgekeerde volgorde waarin je ze hebt aangebracht. Verwijder de proxyvariabelen, stop de client die je met de hand hebt gestart en verwijder elke route- of resolveroverschrijving die je hebt toegevoegd:

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

Een met de hand gestarte client laten draaien is hoe een laptop bij het volgende kantoorbezoek met een kapot netwerk eindigt. Proxyvariabelen die in een shellprofiel achterblijven breken weken later niet-verwante tools, en degene die ze debugt, zal de twee gebeurtenissen niet met elkaar verbinden.

Schrijf dan vier regels: het netwerk, de tijdstempel, de fase die faalde en de uitgever die je zag. Een pad dat op de ene campus werkt en op de volgende faalt is normaal, en de volgende persoon moet weten of het verschil de proxy, de resolver of het filter was. Als het antwoord is dat het netwerk remote toegang verbiedt, stop daar en vraag de beheerder om de ondersteunde route in plaats van een omweg mee te dragen in een beleid dat je niet hebt gelezen.