VPN blokkert i eit nettverk berre for web? Arbeid gjennom laga

Eit campus- eller hotellnettverk der nettlesaren verkar og kvar tunnel døyr, er ikkje eitt problem, men fire stabla. Vegen tillèt kanskje berre TCP 443, krev ein autentisert proxy, inspiserer handtrykket, eller forbyr rett og slett fjernåtkomst gjennom policy. Å ta dei i rekkjefølgje hindrar deg i å kjøpe ein ny klient for å rette ein nettverksregel. Rettleiinga nedanfor tek om lag ti minutt og endar med eit skriftleg svar på kva lag som avviste deg.

Prov kva lag som avviser sambandet

Ikkje start med VPN-klienten. Start med ein vanleg HTTPS-førespurnad til same vert og les tidsfasane, fordi fasen som feilar fortel kva eining som er ansvarleg:

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

Ingen respons og ingen connect-tid betyr at TCP aldri vart fullført, så ein brannmur, eit proxykrav eller ein feil destinasjon er i spel. Ei connect-tid utan tls-tid betyr at noko i midten godtok sambandet og deretter stoppa handtrykket, og slik ser ein inspiserande proxy ut frå klientsida.

Sjå no på sertifikatet du faktisk får. Det er den raskaste måten å finne ut om du snakkar med serveren eller med ein mellomliggjande boks som signerte økta på nytt:

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

Les utstedarlinja. Din eigen CA betyr at du nådde tenesta; ein bedrifts- eller einingutstedar betyr at eit filter avslutta sambandet og avgjer kva som skjer vidare. Ta opp begge utdata med tidsstempel, fordi same test ein time seinare på gjestenettverket kan gje eit anna svar.

Ein proxybevisst klient endrar den første pakken, ikkje policyen

Viss nettverket krev CONNECT gjennom ein autentisert proxy, må VPN-klienten få vite det, elles vil han prøve å opne ein socket til ein adresse han ikkje kan rute. Test proxyen åtskild frå klienten, slik at ein feil har éi 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 kommandoen provar at proxyen vil bere destinasjonen. Den andre ber klienten bruke TCP på 443, den einaste transporten dei fleste web-berre-vegar i det heile sender vidare. Viss den første lukkast og den andre framleis feilar, er proxyen ikkje hindringa.

Nokre klientar les proxyen til operativsystemet i staden for ei overstyring, og nokre les ingen av dei. Sjekk dokumentasjonen til applikasjonen før du går ut frå at ei systemvid innstilling gjeld. Ein klient som løyser endepunktet gjennom ein resolver som proxyen ikkje tenar, vil også feile her, og difor kan ei DNS-endring sjå ut som ei løysing når ho berre er ein omveg.

Legg også merke til styringsmønsteret. Eit filtrert nettverk kan svare på deteksjonsvertsnamnet til ein leverandør med noko eige, noko som endrar kva proxyprofil klienten vel. Ikkje bygg ein prosess rundt den særskildheita. Ho varierer frå stad til stad, endrar seg utan varsel, og det er ikkje noko du kan støtte for andre.

Port 443 er nåbar, ikkje tillaten

Å pakke ein tunnel i TLS på 443 løyser nåbarheit og ingenting anna. Eit filter som sjekkar porten, slepp han gjennom; eit filter som tek fingeravtrykk av handtrykket, gjer det ikkje, og kryptert klienthelsing gøymer berre servernamnet når begge endar støttar det. Køyr testen og finn ut kva slags filter du er bak i staden for å håpe.

Det er også ein ytingskostnad som folk oppdagar seinare. Ein påliteleg transport inne i ein påliteleg transport forsterkar tap, fordi den indre stakken sender på nytt segment som den ytre stakken allereie har sendt på nytt. På ei rein linje merkar ingen det. På eit overbelasta campusnett utan kabel blir tunnelen ubrukeleg akkurat når du treng han, og grafen ser ut som pakketap sjølv om ingenting blir kasta med vilje.

UDP er vanlegvis det første offeret, og det er verdt å stadfeste i staden for å gå ut frå det. Viss WireGuard eller standard OpenVPN aldri fullfører eit handtrykk medan TCP 443 verkar, slepp nettverket UDP, og inga nøkkelregenerering endrar det:

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

Eit tomt handtrykkstidsstempel ved ein peer som verka i går, er UDP-svaret. Dei to DNS-spørjingane svarar på eit anna spørsmål: viss den lokale resolveren og ein offentleg resolver er usamde om adressa til endepunktet, blir du styrt, og transportargumentet er det feil.

Stadfest kva som faktisk forlét maskinen

Klientloggar skildrar kva klienten trur. Eit opptak skildrar kva nettverket såg, og skilnaden mellom dei to er der dei fleste av desse sakene blir løyste:

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

Viss du ser SYN-pakkar og ingen SYN-ACK, er blokkeringa oppstraums og klienten uskuldig. Viss du ser eit fullført handtrykk til ei adresse som ikkje er serveren si, snakkar du med ein proxy eller ein avlyttar. Viss du ikkje ser noko i det heile, sjekk at du tok opptak på rett grensesnitt før du konkluderer noko.

Socket-oppføringa fangar eit meir subtilt tilfelle: ein andre tunnel som allereie held standardruta. To klientar som slåst om rutetabellen gjev periodiske feil som ser nøyaktig ut som eit blokkert nettverk, og opptaket vil vise trafikk som forlèt gjennom eit grensesnitt du ikkje venta.

Tilbakerulling, og notatet som er verdt å behalde

Angre endringane i motsett rekkjefølgje av korleis du gjorde dei. Fjern proxyvariablane, stopp klienten du starta for hand, og fjern kvar rute- eller resolver-overstyring du la til:

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

Å la ein handstarta klient køyre er korleis ein laptop endar med eit øydelagt nettverk ved neste kontorbesøk. Proxyvariablar som blir liggande i ein shellprofil øydelegg urelaterte verktøy veker seinare, og personen som feilsøkjer dei, koplar ikkje dei to hendingane.

Skriv så fire linjer: nettverket, tidsstempelet, fasen som feila, og utstedaren du såg. Ein veg som verkar på ein campus og feilar på den neste, er normal, og neste person må vite om skilnaden var proxyen, resolveren eller filteret. Viss svaret er at nettverket forbyr fjernåtkomst, stopp der og be administratoren om den støtta ruta i staden for å bere ein omveg inn i ein policy du ikkje har lese.