VPN blokkert på et nettverk kun for web? Arbeid gjennom lagene

Et campus- eller hotellnettverk der nettleseren virker og hver tunnel dør, er ikke ett problem, men fire stablet. Veien tillater kanskje bare TCP 443, krever en autentisert proxy, inspiserer håndtrykket, eller forbyr rett og slett fjernadgang gjennom policy. Å ta dem i rekkefølge hindrer deg i å kjøpe en ny klient for å rette en nettverksregel. Veiledningen nedenfor tar omtrent ti minutter og ender med et skriftlig svar på hvilket lag som avviste deg.

Bevis hvilket lag som avviser forbindelsen

Ikke start med VPN-klienten. Start med en vanlig HTTPS-forespørsel til samme vert og les tidsfasene, fordi fasen som feiler forteller hvilken enhet som 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/

Ingen respons og ingen connect-tid betyr at TCP aldri ble fullført, så en brannmur, et proxykrav eller en feil destinasjon er i spill. En connect-tid uten tls-tid betyr at noe i midten godtok forbindelsen og deretter stoppet håndtrykket, og slik ser en inspiserende proxy ut fra klientsiden.

Se nå på sertifikatet du faktisk mottar. Det er den raskeste måten å finne ut om du snakker med serveren eller med en mellomliggende boks som signerte økten på nytt:

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

Les utstederlinjen. Din egen CA betyr at du nådde tjenesten; en bedrifts- eller enhetsutsteder betyr at et filter avsluttet forbindelsen og bestemmer hva som skjer videre. Ta opp begge utdataene med tidsstempel, fordi samme test en time senere på gjestenettverket kan gi et annet svar.

En proxybevisst klient endrer den første pakken, ikke policyen

Hvis nettverket krever CONNECT gjennom en autentisert proxy, må VPN-klienten få vite det, ellers vil den prøve å åpne en socket til en adresse den ikke kan rute. Test proxyen atskilt fra klienten, slik at en feil 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 kommandoen beviser at proxyen vil bære destinasjonen. Den andre ber klienten bruke TCP på 443, den eneste transporten de fleste web-kun-veier i det hele tatt videresender. Hvis den første lykkes og den andre fortsatt feiler, er proxyen ikke hindringen.

Noen klienter leser operativsystemets proxy i stedet for en overstyring, og noen leser ingen av dem. Sjekk applikasjonens egen dokumentasjon før du antar at en systemomfattende innstilling gjelder. En klient som løser endepunktet gjennom en resolver som proxyen ikke betjener, vil også feile her, og derfor kan en DNS-endring se ut som en løsning når den bare er en omvei.

Legg også merke til styringsmønsteret. Et filtrert nettverk kan svare på en leverandørs deteksjonsvertsnavn med noe eget, noe som endrer hvilken proxyprofil klienten velger. Ikke bygg en prosess rundt den særheten. Den varierer fra sted til sted, endres uten varsel, og det er ikke noe du kan støtte for andre.

Port 443 er nåbart, ikke tillatt

Å pakke en tunnel i TLS på 443 løser nåbarhet og ingenting annet. Et filter som sjekker porten, slipper den gjennom; et filter som tar fingeravtrykk av håndtrykket, gjør det ikke, og kryptert klienthello skjuler bare servernavnet når begge ender støtter det. Kjør testen og finn ut hva slags filter du er bak i stedet for å håpe.

Det er også en ytelseskostnad som folk oppdager senere. En pålitelig transport inne i en pålitelig transport forsterker tap, fordi den indre stakken sender på nytt segmenter som den ytre stakken allerede har sendt på nytt. På en ren linje merker ingen det. På et overbelastet campusnett uten kabel blir tunnelen ubrukelig akkurat når du trenger den, og grafen ser ut som pakketap selv om ingenting kastes med vilje.

UDP er vanligvis det første offeret, og det er verdt å bekrefte i stedet for å anta. Hvis WireGuard eller standard OpenVPN aldri fullfører et håndtrykk mens TCP 443 virker, slipper nettverket UDP, og ingen nøkkelregenerering endrer det:

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

Et tomt håndtrykkstidsstempel ved en peer som virket i går, er UDP-svaret. De to DNS-spørringene svarer på et annet spørsmål: hvis den lokale resolveren og en offentlig resolver er uenige om endepunktets adresse, blir du styrt, og transportargumentet er det feil.

Bekreft hva som faktisk forlot maskinen

Klientlogger beskriver hva klienten tror. Et opptak beskriver hva nettverket så, og forskjellen mellom de to er der de fleste av disse sakene 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 blokkeringen oppstrøms og klienten uskyldig. Hvis du ser et fullført håndtrykk til en adresse som ikke er serverens, snakker du med en proxy eller en avlytter. Hvis du ikke ser noe i det hele tatt, sjekk at du tok opptak på riktig grensesnitt før du konkluderer noe.

Socket-oppføringen fanger et mer subtilt tilfelle: en andre tunnel som allerede holder standardruten. To klienter som slåss om rutetabellen gir periodiske feil som ser nøyaktig ut som et blokkert nettverk, og opptaket vil vise trafikk som forlater gjennom et grensesnitt du ikke forventet.

Tilbakerulling, og notatet som er verdt å beholde

Angre endringene i motsatt rekkefølge av hvordan du gjorde dem. Fjern proxyvariablene, stopp klienten du startet for hånd, og fjern enhver rute- eller resolver-overstyring du la til:

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

Å la en håndstartet klient kjøre er hvordan en laptop ender med et ødelagt nettverk ved neste kontorbesøk. Proxyvariabler som blir liggende i en shell-profil ødelegger urelaterte verktøy uker senere, og personen som feilsøker dem, kobler ikke de to hendelsene.

Skriv så fire linjer: nettverket, tidsstempelet, fasen som feilet, og utstederen du så. En vei som virker på ett campus og feiler på det neste, er normal, og neste person må vite om forskjellen var proxyen, resolveren eller filteret. Hvis svaret er at nettverket forbyr fjernadgang, stopp der og be administratoren om den støttede ruten i stedet for å bære en omvei inn i en policy du ikke har lest.