VPN blokované v síti jen pro web? Projděte vrstvy

Kampusová nebo hotelová síť, kde prohlížeč funguje a každý tunel umírá, není jeden problém, ale čtyři vrstvené. Cesta může povolovat jen TCP 443, může vyžadovat autentizovanou proxy, může kontrolovat handshake a může prostě politikou zakázat vzdálený přístup. Když je projdete popořadě, ušetříte si nákup nového klienta na opravu síťového pravidla. Následující postup trvá asi deset minut a končí písemnou odpovědí, která vrstva vás odmítla.

Dokažte, která vrstva spojení odmítá

Nezačínejte u VPN klienta. Začněte obyčejným HTTPS požadavkem na stejný hostitel a čtěte časové fáze, protože fáze, která selže, říká, které zařízení je odpovědné:

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

Žádná odpověď a žádný čas connect znamená, že TCP se nikdy nedokončil, takže ve hře je firewall, požadavek na proxy nebo špatný cíl. Čas connect bez času tls znamená, že něco uprostřed spojení přijalo a pak zablokovalo handshake, což je přesně to, jak vypadá kontrolující proxy z pohledu klienta.

Teď prohlédněte certifikát, který skutečně dostáváte. To je nejrychlejší způsob, jak zjistit, zda mluvíte se serverem, nebo s meziboxem, který relaci znovu podepsal:

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

Přečtěte řádek vydavatele. Vaše vlastní CA znamená, že jste se dostali ke službě; firemní vydavatel nebo vydavatel zařízení znamená, že filtr spojení ukončil a rozhoduje, co bude dál. Zaznamenejte oba výstupy s časovým razítkem, protože stejný test o hodinu později v hostovské síti může dát jinou odpověď.

Klient, který zná proxy, mění první paket, ne politiku

Pokud síť vyžaduje CONNECT přes autentizovanou proxy, musí se to VPN klientovi říct, jinak se pokusí otevřít socket na adresu, kterou neumí směrovat. Otestujte proxy odděleně od klienta, aby selhání mělo jedno vysvětlení:

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

První příkaz dokazuje, že proxy cíl přenese. Druhý žádá klienta o TCP na 443, jediný transport, který většina cest jen pro web vůbec propustí. Pokud první příkaz uspěje a druhý stále selhává, proxy není překážka.

Někteří klienti čtou proxy operačního systému místo přepsání a někteří nečtou ani jedno. Zkontrolujte vlastní dokumentaci aplikace, než budete předpokládat, že systémové nastavení platí. Klient, který koncový bod řeší přes resolver, kterému proxy neposkytuje službu, zde také selže, a proto změna DNS může vypadat jako oprava, když je jen objížďkou.

Všímejte si také vzorce směrování. Filtrovaná síť může na hostname detekce dodavatele odpovědět něčím svým, což mění, který profil proxy klient zvolí. Nestavte proces na té zvláštnosti. Liší se podle místa, mění se bez oznámení a není to něco, co byste mohli podporovat pro někoho jiného.

Port 443 je dostupný, ne povolený

Zabalení tunelu do TLS na 443 řeší dostupnost a nic jiného. Filtr, který kontroluje port, ho propustí; filtr, který snímá otisk handshake, ne, a šifrované klientské hello skryje jméno serveru jen tehdy, když ho obě strany podporují. Spusťte test a zjistěte, za jakým filtrem jste, místo abyste doufali.

Existuje i cena za výkon, kterou lidé objeví později. Spolehlivý transport uvnitř spolehlivého transportu zesiluje ztráty, protože vnitřní zásobník znovu posílá segmenty, které vnější už znovu poslal. Na čistém spoji si toho nikdo nevšimne. V přetížené kampusové bezdrátové síti se tunel stane nepoužitelným přesně ve chvíli, kdy ho potřebujete, a graf vypadá jako ztráta paketů, i když se nic záměrně nezahazuje.

UDP bývá první obětí a vyplatí se to potvrdit, ne odvodit. Pokud WireGuard nebo výchozí OpenVPN nikdy nedokončí handshake, zatímco TCP 443 funguje, síť zahazuje UDP a žádné obnovení klíčů to nezmění:

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

Prázdné časové razítko handshake u partnera, který včera fungoval, je odpověď o UDP. Dva DNS dotazy odpovídají na jinou otázku: pokud se místní resolver a veřejný resolver neshodují na adrese koncového bodu, jste směrováni a argument o transportu je špatný.

Ověřte, co skutečně opustilo stroj

Klientské logy popisují, čemu klient věří. Zachycení popisuje, co viděla síť, a rozdíl mezi nimi je místo, kde se většina těchto případů řeší:

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

Pokud vidíte pakety SYN a žádný SYN-ACK, blok je výš a klient je nevinný. Pokud vidíte dokončený handshake na adresu, která není adresou serveru, mluvíte s proxy nebo odposlouchávačem. Pokud nevidíte nic, ověřte, že jste zachytávali na správném rozhraní, než cokoli uzavřete.

Výpis socketů zachytí jemnější případ: druhý tunel už drží výchozí trasu. Dva klienti bojující o směrovací tabulku vytvářejí přerušované poruchy, které vypadají přesně jako blokovaná síť, a zachycení ukáže provoz odcházející rozhraním, které jste nečekali.

Vrácení zpět a poznámka, kterou stojí za to si nechat

Vraťte změny v opačném pořadí, než jste je dělali. Zrušte proměnné proxy, zastavte klienta, kterého jste spustili ručně, a odstraňte každé přepsání trasy nebo resolveru, které jste přidali:

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

Nechat ručně spuštěného klienta běžet je způsob, jak notebook skončí s rozbitou sítí při příští návštěvě kanceláře. Proměnné proxy ponechané v profilu shellu rozbijí nesouvisející nástroje o týdny později a člověk, který je ladí, ty dvě události nespojí.

Pak napište čtyři řádky: síť, časové razítko, fázi, která selhala, a vydavatele, kterého jste viděli. Cesta, která funguje na jednom kampusu a na dalším selže, je normální a další člověk musí vědět, zda rozdílem byla proxy, resolver nebo filtr. Pokud je odpověď, že síť vzdálený přístup zakazuje, zastavte se tam a požádejte správce o podporovanou cestu, místo abyste nosili obejití do politiky, kterou jste nečetli.