Používa sa DNS vášho VPN naozaj? Zachyťte port 53 a pozrite sa

Opýtajte sa väčšiny ľudí, čo VPN klient robí s DNS, a povedia, že nastavuje resolver, takže dopyty putujú vnútri tunela. Zasunutie je skutočné; predpoklad, že sa z neho stane dopyt, nie. Medzi zasunutou voľbou a paketom na drôte stoja tri fázy a každá zlyháva nezávisle spôsobmi, ktoré všetky vyzerajú ako pokazený DNS server. Preto sa stránka s testom úniku a fungujúci prehliadač môžu rozísť ohľadne toho istého stroja v tom istom okamihu.

Zasunutá voľba nie je dopyt

Prvá fáza je, že server ponúka nastavenia, napríklad zasunutú voľbu DNS, ktorá pomenúva resolver vnútri tunela. Druhá fáza je, že klient tieto nastavenia použije na rozhranie. Tretia fáza je, že aplikácia skutočne pošle dopyt na tú adresu. Zlyhanie v druhej fáze nechá voľbu viditeľnú v protokole spojenia, kým zoznam resolverov zostane nezmenený, a zlyhanie v tretej fáze nechá úplne správny zoznam resolverov nevyužitý.

Väčšina diagnostiky zlieva tie tri do jedného a obviňuje VPN server, ktorý je zvyčajne jediná strana, ktorá dokáže preukázať, že urobila svoju časť. Čítajte namiesto toho skutočný stav resolvera klienta a potom sledujte, ako jeden dopyt odchádza. Tie dve pozorovania oddeľujú konfiguráciu od smerovania a od politiky a stoja okolo piatich minút. Uchovajte záznamy, pretože ďalší inženýr chce stav pred a po, nie ich opis.

Skontrolujte, čo rozhranie skutočne drží

V Linuxe môže byť systémovým resolverom obyčajný súbor, NetworkManager alebo systemd-resolved, a to, kto z nich ho vlastní, rozhoduje, kam zasunutý server dosadne. Proces OpenVPN z príkazového riadka systémový resolver sám neaktualizuje, takže dokumentovanou integráciou je skript up/down alebo správca pripojení, ktorý už vie nastavenia použiť. Spúšťať oboje je účinný spôsob, ako vytvoriť pretek.

resolvectl status
cat /etc/resolv.conf

Vo Windows je zoznam pre každý adaptér, takže tunelový adaptér môže držať interné servery, kým fyzický adaptér si ponecháva miestne a pri niektorých menách vyhráva. Porovnávajte oba adaptéry, nie ten, ktorý považujete za aktívny.

Sledujte jeden dopyt mimo stroja

Zachyťte obe rozhrania súčasne a potom preložte jedno meno, ktoré by malo použiť interný resolver. Tá dvojica záznamov odpovedá na to, na čo nedokáže odpovedať žiadny výstup konfigurácie.

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

Dopyt, ktorý sa objaví na fyzickom rozhraní a nikdy v tuneli, znamená, že klient vybral nesprávny resolver. Dopyt, ktorý sa neobjaví na ani jednom z nich, znamená, že aplikácia odpovedala z vyrovnávacej pamäte, opýtala sa stubu počúvajúceho na loopbacku alebo použila šifrovaný resolver, ktorého prevádzka sa vôbec neobjavuje ako port 53. Zachytávajte aj odpovede, nielen dopyty, pretože dopyt odchádzajúci tunelom s odpoveďou z verejnej adresy je iná porucha než žiadna prichádzajúca odpoveď.

Firewall, ktorý prijíma len vlastný DNS

Komerční klienti niekedy inštalujú vlastné filtračné reťazce. Jeden dokumentovaný vzor povoľuje DNS k vlastnému resolveru klienta a zahadzuje všetku zvyšnú prevádzku UDP na porte 53, ktorá sa pokúša opustiť rozhranie, ktoré nie je loopback, vrátane prevádzky, ktorú používateľ zámerne smeroval inam. Dopyty démona miznú bez stopy, čo sa číta ako zlyhanie resolvera, a nie ako filter.

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

Ak sa pravidlo zahadzovania vyhodnocuje skôr než vaša výnimka, pridané pravidlo sa nikdy nedosiahne, preto ho vložte na prvú pozíciu a obmedzte cieľ na resolver, ktorý skutočne myslíte.

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

Tá výnimka je diagnostická a nie politika. Ak je pravidlo dodávateľa zámerné, podporovanou opravou je nakonfigurovať klienta, aby tento resolver povolil, a rozhodnutie zaznamenať, pretože vložené pravidlo neprežije ďalšiu aktualizáciu klienta.

Prečo stránka s únikom dokazuje menej, než sa zdá

To, čo stránka s testom úniku ukazuje, je resolver, ktorý hovoril s operátorom testu, nie ten, ktorý oslovil váš stroj. Miestny preposielač, ktorý rekurzívne vychádza von, dáva na túto stránku svoju vlastnú výstupnú adresu a šifrované dopyty môžu stránku nechať úplne prázdnu. Oba výsledky sa čítajú nesprávne, jeden ako únik a druhý ako záruka, a ani jedno čítanie nevyplýva z pozorovania.

Obhájiteľným dôkazom je záznam: rozhranie, cieľová adresa, odpoveď a časová pečiatka. Urobte jeden pred zdvihnutím tunela a jeden potom a nabudúce, keď meno zlyhá, ich porovnajte. Tá dvojica tiež povie ďalšiemu človeku, či porucha bola v preklade, smerovaní alebo vo vlastnej prístupovej politike resolvera.