VPN blokeret på et netværk kun til web? Tag lagene

Et campus- eller hotelnetværk, hvor browseren virker og hver tunnel dør, er ikke ét problem, men fire oveni hinanden. Vejen tillader måske kun TCP 443, den kræver måske en godkendt proxy, den inspicerer måske håndtrykket, og den forbyder måske ganske enkelt fjernadgang via politik. At tage dem i rækkefølge forhindrer dig i at købe en ny klient for at rette en netværksregel. Vejledningen nedenfor tager omkring ti minutter og slutter med et skriftligt svar på, hvilket lag der afviste dig.

Bevis hvilket lag der afviser forbindelsen

Start ikke med VPN-klienten. Start med en almindelig HTTPS-anmodning til samme vært og læs tidsfaserne, for den fase der fejler fortæller, hvilken enhed der er ansvarlig:

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

Intet svar og ingen connect-tid betyder, at TCP aldrig blev færdigt, så en firewall, et proxykrav eller en forkert destination er i spil. En connect-tid uden tls-tid betyder, at noget i midten accepterede forbindelsen og derefter stoppede håndtrykket, og sådan ser en inspicerende proxy ud fra klientens side.

Se nu på det certifikat, du faktisk modtager. Det er den hurtigste måde at finde ud af, om du taler med serveren eller med en mellemboks, der har underskrevet sessionen igen:

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

Læs udstederlinjen. Din egen CA betyder, at du nåede tjenesten; en virksomheds- eller enhedsudsteder betyder, at et filter afsluttede forbindelsen og bestemmer, hvad der sker nu. Gem begge output med et tidsstempel, for samme test en time senere på gæstenetværket kan give et andet svar.

En proxybevidst klient ændrer den første pakke, ikke politikken

Hvis netværket kræver CONNECT gennem en godkendt proxy, skal VPN-klienten have det at vide, ellers prøver den at åbne en socket til en adresse, den ikke kan rutte. Test proxyen adskilt fra klienten, så en fejl har én forklaring:

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

Den første kommando beviser, at proxyen bærer destinationen. Den anden beder klienten bruge TCP på 443, den eneste transport, som de fleste web-kun-veje overhovedet videresender. Hvis den første kommando lykkes og den anden stadig fejler, er proxyen ikke hindringen.

Nogle klienter læser styresystemets proxy i stedet for en tilsidesættelse, og nogle læser ingen af dem. Tjek applikationens egen dokumentation, før du antager, at en systemindstilling gælder. En klient, der opløser endepunktet gennem en resolver, som proxyen ikke betjener, vil også fejle her, og derfor kan en DNS-ændring se ud som en løsning, når den kun er en omvej.

Hold også øje med styringsmønstret. Et filtreret netværk kan svare på en leverandørs detekteringsværtsnavn med noget af sit eget, hvilket ændrer, hvilken proxyprofil klienten vælger. Byg ikke en proces omkring den særhed. Den varierer efter sted, ændrer sig uden varsel, og det er ikke noget, du kan understøtte for andre.

Port 443 er nåbar, ikke tilladt

At pakke en tunnel i TLS på 443 løser nåbarhed og intet andet. Et filter, der tjekker porten, lukker den igennem; et filter, der tager fingeraftryk af håndtrykket, gør ikke, og krypteret klienthilsen skjuler kun servernavnet, når begge ender understøtter det. Kør testen og find ud af, hvilken slags filter du er bagved, i stedet for at håbe.

Der er også en ydelsesomkostning, som folk opdager senere. En pålidelig transport inde i en pålidelig transport forstærker tab, fordi den indre stak gensender segmenter, som den ydre stak allerede har gensendt. På et rent link bemærker ingen det. På et overbelastet campus-trådløst netværk bliver tunnelen ubrugelig præcis når du har brug for den, og grafen ser ud som pakketab, selv om intet kastes væk med vilje.

UDP er normalt det første offer, og det er værd at bekræfte i stedet for at antage. Hvis WireGuard eller standard OpenVPN aldrig fuldfører et håndtryk, mens TCP 443 virker, dropper netværket UDP, og ingen nøgleregenerering ændrer det:

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

Et tomt håndtrykstidsstempel ved en peer, der virkede i går, er UDP-svaret. De to DNS-forespørgsler besvarer et andet spørgsmål: hvis den lokale resolver og en offentlig resolver er uenige om endepunktets adresse, bliver du styret, og transportargumentet er det forkerte.

Kontrollér, hvad der faktisk forlod maskinen

Klientlogfiler beskriver, hvad klienten tror. En optagelse beskriver, hvad netværket så, og forskellen mellem de to er, hvor de fleste af disse sager 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'

Hvis du ser SYN-pakker og ingen SYN-ACK, er blokeringen opstrøms, og klienten er uskyldig. Hvis du ser et fuldført håndtryk til en adresse, der ikke er serverens, taler du med en proxy eller en aflytter. Hvis du intet ser, så tjek, at du optog på det rigtige interface, før du konkluderer noget.

Socket-opslagningen fanger et mere subtilt tilfælde: en anden tunnel holder allerede standardruten. To klienter, der slås om routingtabellen, giver periodiske fejl, der ser præcis ud som et blokeret netværk, og optagelsen viser trafik, der forlader gennem et interface, du ikke forventede.

Rul tilbage, og noten der er værd at gemme

Fortryd ændringerne i omvendt rækkefølge af, hvordan du lavede dem. Fjern proxyvariablerne, stop den klient, du startede i hånden, og fjern enhver rute- eller resolver-tilsidesættelse, du tilføjede:

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

At lade en håndstartet klient køre er måden, en laptop ender med et brudt netværk ved næste kontorbesøg. Proxyvariabler efterladt i en shell-profil ødelægger urelaterede værktøjer uger senere, og personen, der fejlfinder dem, forbinder ikke de to begivenheder.

Skriv derefter fire linjer: netværket, tidsstemplet, fasen der fejlede, og den udsteder du så. En vej, der virker på et campus og fejler på det næste, er normal, og den næste person skal vide, om forskellen var proxyen, resolveren eller filteret. Hvis svaret er, at netværket forbyder fjernadgang, så stop der og bed administratoren om den understøttede rute i stedet for at bære en omvej ind i en politik, du ikke har læst.