Používá se DNS vaší VPN skutečně? Zachyťte port 53 a podívejte se

Zeptejte se většiny lidí, co VPN klient dělá s DNS, a řeknou, že nastavuje resolver, takže dotazy putují uvnitř tunelu. Zasunutí je skutečné; předpoklad, že se z něj stane dotaz, nikoli. Mezi zasunutou volbou a paketem na drátě stojí tři fáze a každá selhává nezávisle způsoby, které všechny vypadají jako rozbitý DNS server. Proto se stránka s testem úniku a fungující prohlížeč mohou rozejít ohledně stejného stroje ve stejný okamžik.

Zasunutá volba není dotaz

První fáze je, že server nabízí nastavení, například zasunutou volbu DNS, která jmenuje resolver uvnitř tunelu. Druhá fáze je, že klient tato nastavení použije na rozhraní. Třetí fáze je, že aplikace skutečně pošle dotaz na tuto adresu. Selhání ve druhé fázi nechá volbu viditelnou v protokolu spojení, zatímco seznam resolverů zůstane nezměněný, a selhání ve třetí fázi nechá naprosto správný seznam resolverů nevyužitý.

Většina diagnostiky slévá tyto tři do jedné a viní VPN server, který je obvykle jedinou stranou, jež dokáže prokázat, že svou část udělala. Čtěte místo toho skutečný stav resolveru klienta a potom sledujte, jak jeden dotaz odchází. Tato dvě pozorování oddělují konfiguraci od směrování a od politiky a stojí kolem pěti minut. Uchovejte záznamy, protože další inženýr chce stav před a po, ne jejich popis.

Zkontrolujte, co rozhraní skutečně drží

V Linuxu může být systémovým resolverem obyčejný soubor, NetworkManager nebo systemd-resolved a to, kdo z nich ho vlastní, rozhoduje, kam zasunutý server dosedne. Proces OpenVPN z příkazové řádky systémový resolver sám neaktualizuje, takže dokumentovanou integrací je skript up/down nebo správce připojení, který už umí nastavení použít. Spouštět obojí je účinný způsob, jak vytvořit závod.

resolvectl status
cat /etc/resolv.conf

Ve Windows je seznam pro každý adaptér, takže tunelový adaptér může držet interní servery, zatímco fyzický adaptér si ponechává místní a u některých jmen vyhrává. Porovnávejte oba adaptéry, ne ten, který považujete za aktivní.

Sledujte jeden dotaz mimo stroj

Zachyťte obě rozhraní současně a potom přeložte jedno jméno, které by mělo použít interní resolver. Tahle dvojice záznamů odpovídá na to, na co nedokáže odpovědět žádný výstup konfigurace.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Dotaz, který se objeví na fyzickém rozhraní a nikdy v tunelu, znamená, že klient vybral špatný resolver. Dotaz na ani jednom z nich znamená, že aplikace odpověděla z mezipaměti, zeptala se stubu naslouchajícího na loopbacku nebo použila šifrovaný resolver, jehož provoz se vůbec neobjevuje jako port 53. Zachycujte i odpovědi, ne jen dotazy, protože dotaz odcházející tunelem s odpovědí z veřejné adresy je jiná závada než žádná přicházející odpověď.

Firewall, který přijímá jen svůj vlastní DNS

Komerční klienti někdy instalují vlastní filtrační řetězce. Jeden dokumentovaný vzor povoluje DNS k vlastnímu resolveru klienta a zahazuje veškerý zbývající provoz UDP na portu 53, který se pokouší opustit rozhraní, jež není loopback, včetně provozu, který uživatel záměrně nasměroval jinam. Dotazy démona mizí beze stopy, což se čte jako selhání resolveru, a ne jako filtr.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Pokud se pravidlo zahazování vyhodnocuje dřív než vaše výjimka, přidané pravidlo se nikdy nedosáhne, takže ho vložte na první pozici a omezte cíl na resolver, který skutečně míníte.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Tato výjimka je diagnostická, ne politická. Pokud je pravidlo dodavatele záměrné, podporovanou opravou je nakonfigurovat klienta, aby tento resolver povolil, a rozhodnutí zaznamenat, protože vložené pravidlo nepřežije příští aktualizaci klienta.

Proč stránka s únikem dokazuje méně, než se zdá

To, co stránka s testem úniku ukazuje, je resolver, který mluvil s operátorem testu, ne ten, který oslovil váš stroj. Místní přesměrovávač, který rekurzivně vychází ven, dává na tuto stránku svou vlastní výstupní adresu a šifrované dotazy mohou stránku nechat úplně prázdnou. Oba výsledky se čtou špatně, jeden jako únik a druhý jako záruka, a ani jedno čtení z pozorování nevyplývá.

Obhájitelným důkazem je záznam: rozhraní, cílová adresa, odpověď a časové razítko. Udělejte jeden před zvednutím tunelu a jeden potom a příště, až jméno selže, je porovnejte. Tahle dvojice také řekne dalšímu člověku, zda závada byla v překladu, směrování nebo ve vlastní přístupové politice resolveru.