VPN blockerat i ett nätverk bara för webb? Arbeta igenom lagren

Ett campus- eller hotellnätverk där webbläsaren fungerar och varje tunnel dör är inte ett problem utan fyra staplade. Vägen kanske bara tillåter TCP 443, kräver en autentiserad proxy, inspekterar handskakningen eller förbjuder fjärråtkomst helt enkelt via policy. Att arbeta igenom dem i ordning hindrar dig från att köpa en ny klient för att laga en nätverksregel. Guiden nedan tar ungefär tio minuter och slutar med ett skriftligt svar om vilket lager som avvisade dig.

Bevisa vilket lager som avvisar anslutningen

Börja inte med VPN-klienten. Börja med en vanlig HTTPS-begäran till samma värd och läs tidsfaserna, eftersom fasen som misslyckas talar om vilken enhet som ansvarar:

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

Inget svar och ingen connect-tid betyder att TCP aldrig slutfördes, så en brandvägg, ett proxykrav eller en felaktig destination är i spel. En connect-tid utan tls-tid betyder att något i mitten accepterade anslutningen och sedan stoppade handskakningen, och så ser en inspekterande proxy ut från klientsidan.

Titta nu på certifikatet du faktiskt får. Det är det snabbaste sättet att ta reda på om du pratar med servern eller med en mellanlåda som signerade sessionen på nytt:

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

Läs utfärdarens rad. Din egen CA betyder att du nådde tjänsten; en företags- eller enhetsutfärdare betyder att ett filter avslutade anslutningen och bestämmer vad som händer härnäst. Spara båda utdata med tidsstämpel, eftersom samma test en timme senare på gästnätverket kan ge ett annat svar.

En proxy-medveten klient ändrar det första paketet, inte policyn

Om nätverket kräver CONNECT via en autentiserad proxy måste VPN-klienten få veta det, annars försöker den öppna en socket till en adress den inte kan routa. Testa proxyn separat från klienten, så att ett fel har en enda förklaring:

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

Det första kommandot bevisar att proxyn bär destinationen. Det andra ber klienten använda TCP på 443, det enda transportmedel som de flesta webb-bara vägar över huvud taget vidarebefordrar. Om det första lyckas och det andra fortfarande misslyckas är proxyn inte hindret.

Vissa klienter läser operativsystemets proxy i stället för en åsidosättning, och vissa läser ingen av dem. Kontrollera programmets egen dokumentation innan du antar att en systemomfattande inställning gäller. En klient som löser slutpunkten via en resolver som proxyn inte betjänar kommer också att misslyckas här, och det är därför en DNS-ändring kan se ut som en lösning när den bara är en omväg.

Lägg också märke till styrningsmönstret. Ett filtrerat nätverk kan svara på en leverantörs detekteringsvärdnamn med något eget, vilket ändrar vilken proxyprofil klienten väljer. Bygg inte en process kring den egenheten. Den varierar mellan platser, ändras utan varsel och är inget du kan stödja för någon annan.

Port 443 är nåbar, inte tillåten

Att packa in en tunnel i TLS på 443 löser nåbarheten och inget annat. Ett filter som kontrollerar porten släpper igenom den; ett filter som tar fingeravtryck av handskakningen gör det inte, och krypterad klienthälsning döljer bara servernamnet när båda ändarna stöder det. Kör testet och ta reda på vilken sorts filter du är bakom i stället för att hoppas.

Det finns också en prestandakostnad som folk upptäcker senare. En tillförlitlig transport inuti en tillförlitlig transport förstärker förlust, eftersom den inre stacken skickar om segment som den yttre redan har skickat om. På en ren länk märker ingen det. I ett överbelastat campusnät utan kabel blir tunneln oanvändbar precis när du behöver den, och grafen ser ut som paketförlust trots att inget kastas bort med avsikt.

UDP är oftast det första offret, och det är värt att bekräfta i stället för att anta. Om WireGuard eller standard-OpenVPN aldrig slutför en handskakning medan TCP 443 fungerar, släpper nätverket UDP, och ingen nyckelregenerering ändrar det:

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

En tom tidsstämpel för handskakningen bredvid en peer som fungerade i går är UDP-svaret. De två DNS-frågorna svarar på en annan fråga: om den lokala resolvern och en offentlig resolver inte är överens om slutpunktens adress blir du styrd, och transportargumentet är det felaktiga.

Verifiera vad som faktiskt lämnade maskinen

Klientloggar beskriver vad klienten tror. En inspelning beskriver vad nätverket såg, och skillnaden mellan de två är där de flesta av dessa fall löses:

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

Om du ser SYN-paket och ingen SYN-ACK är blockeringen uppströms och klienten oskyldig. Om du ser en slutförd handskakning till en adress som inte är serverns talar du med en proxy eller en avlyssnare. Om du inte ser något alls, kontrollera att du fångade på rätt gränssnitt innan du drar någon slutsats.

Socketlistan fångar ett mer subtilt fall: en andra tunnel som redan håller standardrutten. Två klienter som slåss om routingtabellen ger intermittenta fel som ser exakt ut som ett blockerat nätverk, och inspelningen visar trafik som lämnar via ett gränssnitt du inte förväntade dig.

Återställning, och anteckningen som är värd att spara

Ångra ändringarna i omvänd ordning mot hur du gjorde dem. Ta bort proxyvariablerna, stoppa klienten du startade för hand och ta bort varje rutt- eller resolver-åsidosättning du lade till:

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

Att låta en handstartad klient köra är hur en laptop hamnar med ett trasigt nätverk vid nästa kontorsbesök. Proxyvariabler som lämnas i en shell-profil bryter orelaterade verktyg veckor senare, och personen som felsöker dem kopplar inte ihop de två händelserna.

Skriv sedan fyra rader: nätverket, tidsstämpeln, fasen som misslyckades och utfärdaren du såg. En väg som fungerar på ett campus och misslyckas på nästa är normal, och nästa person behöver veta om skillnaden var proxyn, resolvern eller filtret. Om svaret är att nätverket förbjuder fjärråtkomst, stanna där och be administratören om den stödda vägen i stället för att bära en omväg in i en policy du inte har läst.