Proč hotspot přesměrovává DNS ještě před připojením VPN?

Připojení k hotelové síti staví před vás dvě rozhodnutí o DNS v různých okamžicích: dotazy, které zařízení provede při přihlašování, a dotazy po spuštění tunelu. Hotspot může ovlivnit první z nich prostřednictvím sítě, kterou ovládá. Druhé závisí na politice samotného klienta, což je samostatná věc k prozkoumání.

Projděte spojení popořadě, od prvního DHCP pronájmu k dotazu, který přeložil soukromé jméno. Potom se dvě závady, které v tiketu podpory vypadají stejně, čistě oddělí: jedna nastala před vznikem tunelu, druhá uvnitř něj.

Čeho se hotspot může a nemůže dotknout

Přístupová síť přiděluje adresu resolveru přes DHCP a může zachytit port 53 směrem k této adrese. To stačí k tomu, aby každý nechráněný dotaz dostal adresu portálu nebo blokovací stránku. Stačí to i k rozbití VPN klienta, jehož koncový bod je zapsán jako název hostitele.

Co hotspot nedokáže, je číst nebo přepisovat dotaz, jakmile putuje uvnitř ustaveného tunelu, za předpokladu, že tunel dotaz skutečně nese. Zachycení závisí na tom, že je vidět otázka v otevřeném textu.

Dotazy nicméně opouštějí tunel z důvodů nesouvisejících s hotspotem: nastavení zabezpečeného DNS v prohlížeči, pravidlo split-DNS, které drží firemní příponu na místním resolveru, nebo klient nakonfigurovaný tak, aby DNS z tunelu vyloučil. Každé je volbou na straně klienta a každé zvenčí vypadá jako rušení hotspotu.

Počáteční dotaz nastává před vznikem tunelu

Klient, kterému je zadán název hostitele, jej musí nejprve přeložit, a v tom okamžiku dotaz žádný tunel nechrání. Pokud hotspot odpoví adresou portálu, vyjednávání selže nebo se zasekne. Pokud neodpoví ničím, klient ohlásí chybu jména a tunel se nikdy nespustí. Každý z obou výsledků vysvětluje prázdný protokol tunelu, který jinak vypadá nevinně.

Operační systémy provádějí i vlastní kontroly konektivity a zjišťování portálu, popsané v RFC 8910 a RFC 8952, a tyto požadavky odcházejí dřív, než je jakákoli VPN spuštěna. Vidět je v protokolu proxy je očekávané chování, nikoli důkaz úniku.

Praktickým řešením je dát klientovi koncový bod, který nepotřebuje dotaz. Když to není možné, dokončete nejdřív přihlášení a připojte se potom.

Zjistěte, který resolver odpověděl

Ptejte se systému, ne prohlížeče, a spusťte dotaz dvakrát: jednou přes resolver, který zařízení právě používá, jednou proti pevné adrese.

resolvectl query vpn.example.com
dig +short vpn.example.com
dig +short vpn.example.com @1.1.1.1

Odpověď z prvního příkazu, která se liší od třetího, vám říká, že místní resolver vrací něco jiného, což je přesně to, co dělá přesměrovávající hotspot. Selhání třetího spolu s úspěchem prvního ukazuje na portál: místní resolver posloužil přihlašovací adresu, zatímco odchozí port 53 byl zahozen. Časové limity u obou znamenají, že síť zahazuje DNS, dokud se nedokončí ověřování.

Po připojení postup zopakujte a porovnejte. Uložená odpověď přežije přechod, proto vyprázdněte mezipaměť nebo se pro druhé pozorování zeptejte na nové jméno.

Udržte pozdější dotazy na cestě, kterou jste zamýšleli

Profil plného tunelu, který zachycuje i DNS, je nejjednodušší uspořádání: každý dotaz z každé aplikace jde k resolveru, který tunel protlačuje, a místní síť vidí jen šifrovaný provoz. Dokažte to tak, že po připojení přeložíte interní a veřejné jméno a potom obě odpovědi porovnáte s tím, co resolver tunelu vrací sám.

Split-DNS potřebuje seznam domén napsaný s úmyslem: firemní přípony tunelem, vše ostatní lokálně a žádné překrývání mezi oběma.

Zabezpečené DNS prohlížeče stojí mimo tuto politiku, takže pokud musí být vypnuté, aby se profil choval předvídatelně, vypněte je pro tento profil, ne pro celý počítač. Udělejte to v nastavení prohlížeče, ne úpravou systémového resolveru, aby byla změna příště vidět. Zaznamenejte odpověď, resolver a fázi připojení do jednoho řádku na test. Zpráva, že DNS na hotelovém Wi-Fi selhalo, popisuje symptom s nejméně třemi různými příčinami.