VPN zablokované v sieti len pre web? Prejdite vrstvy
Prehliadač funguje, tunel umiera. Prečítajte si časové fázy curl, otestujte proxy, overte, či je 443 naozaj povolený, a potom zachyťte, čo opustilo stroj.
Kampusová alebo hotelová sieť, kde prehliadač funguje a každý tunel umiera, nie je jeden problém, ale štyri vrstvy. Cesta môže povoľovať len TCP 443, vyžadovať autentifikovanú proxy, kontrolovať handshake alebo jednoducho politikou zakázať vzdialený prístup. Ich spracovanie po poradí vás ušetrí kupovania nového klienta na opravu sieťového pravidla. Návod nižšie trvá asi desať minút a končí písomnou odpoveďou, ktorá vrstva vás odmietla.
Dokážte, ktorá vrstva spojenie odmieta
Nezačínajte klientom VPN. Začnite obyčajnou HTTPS požiadavkou na ten istý hostiteľ a čítajte časové fázy, pretože fáza, ktorá zlyhá, hovorí, ktoré zariadenie je zodpovedné:
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
--max-time 8 https://vpn.example.net/
Žiadna odpoveď a žiadny čas connect znamená, že TCP sa nikdy nedokončil, takže v hre je firewall, požiadavka na proxy alebo zlý cieľ. Čas connect bez času tls znamená, že niečo uprostred spojenie prijalo a potom zastavilo handshake, a presne tak vyzerá kontrolujúca proxy z pohľadu klienta.
Teraz si pozrite certifikát, ktorý skutočne dostávate. Je to najrýchlejší spôsob, ako zistiť, či hovoríte so serverom alebo s medzikrabicou, ktorá reláciu znovu podpísala:
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null
Prečítajte riadok vydavateľa. Vaše vlastné CA znamená, že ste sa dostali k službe; firemný alebo zariadenový vydavateľ znamená, že filter spojenie ukončil a rozhoduje, čo bude ďalej. Zaznamenajte oba výstupy s časovou pečiatkou, pretože ten istý test o hodinu neskôr v hosťovskej sieti môže dať inú odpoveď.
Klient, ktorý pozná proxy, mení prvý paket, nie politiku
Ak sieť vyžaduje CONNECT cez autentifikovanú proxy, treba to klientovi VPN povedať, inak sa pokúsi otvoriť socket na adresu, ktorú nevie smerovať. Otestujte proxy oddelene od klienta, aby zlyhanie malo jedno vysvetlenie:
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
Prvý príkaz dokazuje, že proxy prenesie cieľ. Druhý žiada klienta používať TCP na 443, jediný transport, ktorý väčšina ciest len pre web vôbec prepustí. Ak prvý uspeje a druhý stále zlyháva, proxy nie je prekážka.
Niektorí klienti čítajú proxy operačného systému namiesto prepísania a niektorí nečítajú ani jedno. Skontrolujte vlastnú dokumentáciu aplikácie, než budete predpokladať, že systémové nastavenie platí. Klient, ktorý rieši koncový bod cez resolver, ktorý proxy neobsluhuje, tu tiež zlyhá, a preto zmena DNS môže vyzerať ako oprava, keď je len obchádzkou.
Všimnite si aj vzorec smerovania. Filtrovaná sieť môže odpovedať na hostname detekcie dodávateľa niečím vlastným, čo mení, ktorý profil proxy klient vyberie. Nestavajte proces na tej zvláštnosti. Líši sa podľa miesta, mení sa bez oznámenia a nie je to niečo, čo môžete podporovať pre niekoho iného.
Port 443 je dostupný, nie povolený
Zabalenie tunela do TLS na 443 rieši dostupnosť a nič iné. Filter, ktorý kontroluje port, ho prepustí; filter, ktorý sníma odtlačok handshake, nie, a šifrované klientske hello skryje meno servera len vtedy, keď ho podporujú obe strany. Spustite test a zistite, za akým filtrom ste, namiesto toho, aby ste dúfali.
Existuje aj cena za výkon, ktorú ľudia objavia neskôr. Spoľahlivý transport vnútri spoľahlivého transportu zosilňuje straty, pretože vnútorný zásobník znovu posiela segmenty, ktoré vonkajší už znovu poslal. Na čistom spoji si to nikto nevšimne. V preťaženej kampusovej bezdrôtovej sieti sa tunel stane nepoužiteľným presne vtedy, keď ho potrebujete, a graf vyzerá ako strata paketov, hoci sa nič zámerne nezahadzuje.
UDP býva prvou obeťou a oplatí sa to potvrdiť, nie odvodiť. Ak WireGuard alebo predvolený OpenVPN nikdy nedokončí handshake, kým TCP 443 funguje, sieť zahadzuje UDP, a žiadne obnovenie kľúčov to nezmení:
sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1
Prázdna časová pečiatka handshake vedľa partnera, ktorý včera fungoval, je odpoveď o UDP. Dve DNS otázky odpovedajú na inú otázku: ak sa miestny resolver a verejný resolver nezhodujú na adrese koncového bodu, ste smerovaní a argument o transporte je nesprávny.
Overte, čo skutočne opustilo stroj
Klientske logy opisujú, čomu klient verí. Zachytenie opisuje, čo videla sieť, a rozdiel medzi nimi je miesto, kde sa väčšina týchto prípadov rieši:
sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'
Ak vidíte pakety SYN a žiadny SYN-ACK, blok je vyššie a klient je nevinný. Ak vidíte dokončený handshake na adresu, ktorá nie je adresou servera, hovoríte s proxy alebo odpočúvačom. Ak nevidíte nič, overte, že ste zachytávali na správnom rozhraní, než čokoľvek uzavriete.
Zoznam socketov zachytí jemnejší prípad: druhý tunel už drží predvolenú trasu. Dvaja klienti bojujúci o smerovaciu tabuľku vytvárajú prerušované poruchy, ktoré vyzerajú presne ako blokovaná sieť, a zachytenie ukáže prevádzku odchádzajúcu rozhraním, ktoré ste nečakali.
Vrátenie späť a poznámka, ktorú sa oplatí nechať si
Vráťte zmeny v opačnom poradí, než ste ich urobili. Odstráňte premenné proxy, zastavte klienta, ktorého ste spustili ručne, a odstráňte akékoľvek prepísanie trasy alebo resolvera, ktoré ste pridali:
unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default
Nechať ručne spusteného klienta bežať je spôsob, akým notebook skončí s pokazenou sieťou pri ďalšej návšteve kancelárie. Premenné proxy ponechané v profile shellu pokazia nesúvisiace nástroje o týždne neskôr a človek, ktorý ich ladí, tie dve udalosti nespojí.
Potom napíšte štyri riadky: sieť, časovú pečiatku, fázu, ktorá zlyhala, a videného vydavateľa. Cesta, ktorá funguje na jednom kampuse a na ďalšom zlyhá, je normálna a ďalší človek musí vedieť, či rozdielom bola proxy, resolver alebo filter. Ak je odpoveď, že sieť zakazuje vzdialený prístup, zastavte sa tam a požiadajte správcu o podporovanú cestu, namiesto toho, aby ste nosili obchádzku do politiky, ktorú ste nečítali.