VPN blokiran na mreži samo za web? Radite po slojevima
Preglednik radi, tunel umire. Pročitajte curl faze vremena, testirajte proxy, provjerite je li 443 stvarno dozvoljen, zatim snimite šta je napustilo mašinu.
Mreža na kampusu ili u hotelu gdje preglednik radi a svaki tunel umire nije jedan problem, to su četiri naslagana. Putanja može dozvoljavati samo TCP 443, može zahtijevati autentificirani proxy, može pregledati handshake i može jednostavno zabraniti udaljeni pristup pravilom. Radeći ih po redu sprječavate se da kupite novi klijent da popravite mrežno pravilo. Uputa ispod traje oko deset minuta i završava pisanim odgovorom o tome koji vas je sloj odbio.
Dokažite koji sloj odbija vezu
Ne počinjite s VPN klijentom. Počnite običnim HTTPS zahtjevom prema istom hostu i pročitajte faze vremena, jer faza koja ne uspije govori koji je uređaj odgovoran:
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
--max-time 8 https://vpn.example.net/
Nema odgovora i nema vremena connect znači da TCP nikad nije završen, pa je u igri firewall, zahtjev za proxy ili pogrešno odredište. Vrijeme connect bez vremena tls znači da je nešto u sredini prihvatilo vezu i zatim zaustavilo handshake, a tako izgleda proxy koji pregleda sa strane klijenta.
Sada pregledajte certifikat koji stvarno primate. To je najbrži način da saznate razgovarate li sa serverom ili sa međukutijom koja je potpisala sesiju iznova:
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null
Pročitajte red izdavaoca. Vaš vlastiti CA znači da ste stigli do usluge; korporativni izdavač ili izdavač uređaja znači da je filter prekinuo vezu i odlučuje šta slijedi. Zabilježite oba izlaza s vremenskom oznakom, jer isti test sat kasnije na gostujućoj mreži može dati drugačiji odgovor.
Klijent svjestan proxyja mijenja prvi paket, ne pravilo
Ako mreža zahtijeva CONNECT kroz autentificirani proxy, VPN klijent mora biti obaviješten o tome, inače će pokušati otvoriti socket prema adresi koju ne može rutirati. Testirajte proxy odvojeno od klijenta, da kvar ima jedno objašnjenje:
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
Prva naredba dokazuje da će proxy prenijeti odredište. Druga traži da klijent koristi TCP na 443, jedini transport koji većina putanja samo za web uopće propušta. Ako prva naredba uspije a druga i dalje ne, proxy nije prepreka.
Neki klijenti čitaju proxy operativnog sistema umjesto nadjačavanja, a neki ne čitaju ni jedno. Provjerite vlastitu dokumentaciju aplikacije prije nego pretpostavite da sistemska postavka važi. Klijent koji rješava odredište preko resolvera kojem proxy ne služi također će ovdje pasti, i zato promjena DNS-a može izgledati kao popravka kad je samo zaobilaznica.
Pazite i na obrazac usmjeravanja dok ste kod toga. Filtrirana mreža može na hostname za detekciju dobavljača odgovoriti nečim svojim, što mijenja koji profil proxyja klijent bira. Ne gradite proces oko te osobenosti. Ona varira po lokaciji, mijenja se bez najave i nije nešto što možete podržavati za nekog drugog.
Port 443 je dostupan, ali nije dozvoljen
Umotavanje tunela u TLS na 443 rješava dostupnost i ništa drugo. Filter koji provjerava port propustit će ga; filter koji uzima otisak handshakea neće, a enkriptirani pozdrav klijenta skriva ime servera samo kad ga podržavaju obje strane. Pokrenite test i saznajte iza koje vrste filtera ste umjesto da se nadate.
Postoji i cijena učinka koju ljudi otkriju kasnije. Pouzdan transport unutar pouzdanog transporta pojačava gubitak, jer unutrašnji stog ponovo šalje segmente koje je vanjski stog već ponovo poslao. Na čistoj vezi to niko ne primijeti. Na zagušenoj kampusskoj bežičnoj mreži tunel postaje neupotrebljiv tačno kad vam treba, a grafikon izgleda kao gubitak paketa iako se ništa ne odbacuje namjerno.
UDP je obično prva žrtva i to vrijedi potvrditi umjesto pretpostaviti. Ako WireGuard ili zadani OpenVPN nikad ne završi handshake dok TCP 443 radi, mreža odbacuje UDP i nikakvo regenerisanje ključeva to neće promijeniti:
sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1
Prazna vremenska oznaka handshakea pored partnera koji je radio jučer odgovor je za UDP. Dva DNS upita odgovaraju na drugo pitanje: ako se lokalni resolver i javni resolver ne slažu o adresi odredišta, vas usmjeravaju i argument o transportu je pogrešan.
Provjerite šta je zaista napustilo mašinu
Klijentski zapisi opisuju šta klijent vjeruje. Snimak opisuje šta je mreža vidjela, a razlika između njih je mjesto gdje se rješava većina ovih slučajeva:
sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'
Ako vidite SYN pakete i nema SYN-ACK, blok je uzvodno i klijent je nevin. Ako vidite završen handshake prema adresi koja nije serverova, razgovarate s proxyjem ili presretačem. Ako ne vidite ništa, provjerite da ste snimali na pravom interfejsu prije nego zaključite bilo šta.
Popis socketa hvata suptilniji slučaj: drugi tunel već drži zadanu rutu. Dva klijenta koja se bore za routing tabelu stvaraju povremene kvarove koji izgledaju tačno kao blokirana mreža, a snimak će pokazati saobraćaj kako izlazi kroz interfejs koji niste očekivali.
Vraćanje i bilješka koju vrijedi sačuvati
Poništite promjene obrnutim redoslijedom od onog kojim ste ih pravili. Uklonite proxy varijable, zaustavite klijent koji ste pokrenuli ručno i uklonite svako nadjačavanje rute ili resolvera koje ste dodali:
unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default
Ostavljanje ručno pokrenutog klijenta da radi je način na koji laptop završi sa pokvarenom mrežom pri sljedećoj posjeti kancelariji. Proxy varijable ostavljene u profilu školjke kvare nepovezane alate sedmicama kasnije, a osoba koja ih otklanja neće povezati dva događaja.
Zatim napišite četiri reda: mreža, vremenska oznaka, faza koja nije uspjela i izdavalac kojeg ste vidjeli. Putanja koja radi na jednom kampusu a pada na sljedećem je normalna, a sljedeća osoba treba znati je li razlika bila proxy, resolver ili filter. Ako je odgovor da mreža zabranjuje udaljeni pristup, zaustavite se tu i pitajte administratora za podržanu putanju umjesto da nosite zaobilaznicu u pravilo koje niste pročitali.