Interné názvy zlyhávajú cez VPN, kým verejné stránky sa prekladajú

Jeden používateľ hlási, že názov hostiteľa z intranetu sa cez VPN neprekladá. Druhá správa z toho istého notebooku hovorí, že test úniku stále ukazuje dopyty, na ktoré odpovedá lokálny resolver. Znejú ako jeden problém a sú to dva, s rôznymi dôkazmi, a obvyklá oprava prvého zhoršuje druhý. Oddeľte ich, skôr než sa dotknete akéhokoľvek nastavenia.

Dva príznaky, ktoré nie sú jedna porucha

Zlyhanie pri preklade interného názvu znamená, že otázka odišla niekam, kde na ňu nemajú odpoveď. Dopyty, ktoré opúšťajú tunel, znamenajú, že otázka odišla na zlé miesto, aj keď odpoveď bola k dispozícii. Sú to opačné poruchy: jedna je chýbajúca odpoveď, druhá je cieľ navyše.

Pasca je v tom, že pridanie kancelárskeho resolvera všade opraví prvú a zaručí druhú. Pridanie verejného resolvera všade robí opak.

Zapíšte obe pozorovania s časovou značkou a potom prejdite štyri kontroly nižšie v poradí.

Ktorý resolver adaptéra dostane otázku

V systéme Windows klient DNS vyberá servery podľa poradia priradenia adaptérov a adaptér tunela nie je automaticky prvý. Otvorte rozšírené nastavenia adaptéra a presuňte pripojenie vzdialeného prístupu nad fyzický adaptér, potom sa znova pripojte, aby sa zmena prejavila v novej relácii.

Poradie priradenia je len prvá polovica. Klient tiež musí vedieť, ktoré názvy patria tomu adaptéru, a to je otázka prípony, nie poradia.

Položte ipconfig /all funkčného počítača vedľa výstupu z notebooku, oba získané so zapnutým tunelom. Funkčný počítač ukáže na kancelárskom adaptéri príponu DNS špecifickú pre pripojenie a notebook na tuneli nemusí ukázať žiadnu. Ten rozdiel vysvetľuje celú triedu hlásení, že server je priamo tam a názov napriek tomu zlyháva, pretože bez prípony sa krátky názov nikdy nedoplní do zóny, ktorú kancelársky resolver obsluhuje.

Krátky názov potrebuje príponu skôr než trasu

Zadanie nekvalifikovaného názvu hostiteľa žiada resolver, aby uhádol doménu. Hádanie prichádza zo zoznamu prípon pripojeného k spojeniu, a ak je ten zoznam prázdny, dopyt odchádza ako jediný štítok, ktorý žiadna súkromná zóna nezosúladí.

Skopírujte príponu funkčného počítača do vlastností IPv4 adaptéra VPN na karte DNS a znova sa pripojte. V Linuxe je ekvivalentom doména vyhľadávania na odkaze tunela, ktorú systemd-resolved sprístupňuje pre každé spojenie, nie globálne.

Držte obe nastavenia v poznámkach oddelene. Prípona mení, na čo sa pýtame; adresa resolvera mení, koho sa pýtame. Oprava jedného pri nesprávnom druhom dáva výsledok, ktorý vyzerá náhodne.

Opýtajte sa priamo resolvera, potom názvu

Priamy dopyt na kancelársky resolver oddeľuje problém názvu od problému cesty, pretože úplne obchádza výber resolvera na klientovi.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Prvý príkaz sa pýta konkrétneho servera na plne kvalifikovaný názov. Ak odpovie, resolver aj cesta k nemu sú v poriadku a porucha je vo výbere alebo v prípone. Ak vyprší čas, adresa je nesprávna alebo nedosiahnuteľná a problém je v smerovaní, nie v DNS. Druhý príkaz ukazuje, čo sa deje s krátkym názvom, a tretí vypíše konfiguráciu resolvera po spojeniach na hoste so systemd.

Dávajte pozor na zástupné odpovede, ktoré niektoré siete vracajú na neznáme názvy. Vierohodná odpoveď nie je dôkazom, že odpovedal zamýšľaný server, preto porovnajte vrátenú adresu s tou, ktorú interná služba skutočne používa. Ak adresa patrí parkovacej stránke alebo proxy, resolver odpovedal, ale odpoveď nikdy nebola vaša. Ten rozdiel ušetrí hodinu naháňania tunela, ktorý celý čas fungoval.

V Linuxe klient VPN, ktorý prepisuje /etc/resolv.conf, úplne nahrádza lokálne resolvery. vpnc sprístupňuje DNSUpdate no, aby to zastavil, a systemd-resolved môže smerovať na odkaz tunela len uvedené domény. Oba prístupy ponechávajú verejné názvy lokálnemu resolveru a interné názvy posielajú do kancelárie.

Úniky sú pravidlo, nie zaškrtávacie pole

Preklad názvov je výmena UDP na port 53, takže tunel, ktorý prenáša webovú prevádzku ale nie UDP, necháva dopyt na fyzickej ceste. Dokážte to zachytením na fyzickej sieťovej karte počas prekladu verejného názvu. Dopyt viditeľný na tom rozhraní v čitateľnej podobe znamená, že ho tunel neprenáša.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ak sa dopyt objaví na tom rozhraní v čitateľnej podobe, tunel ho neprenáša. Oprava je pravidlo, ktoré povoľuje port 53 len resolveru vtlačenému VPN a ostatné ciele zahadzuje, plus konfigurácia klienta, ktorá vtlačenú možnosť ticho nezahodí.

Posledná časť je dôležitejšia, než vyzerá. Spustite OpenVPN s route-nopull a vtlačená možnosť DNS zmizne spolu s trasami, ak sa filter pull nerozšíri, aby ju udržal. A klient, ktorý ignoruje dhcp-option DNS, bude naďalej používať to, čo mal predtým. Akákoľvek zmena na strane servera potrebuje novú reláciu, keďže zoznam resolverov sa doručuje pri nadvihnutí tunela a zastaraná relácia stále ukazuje starý stav.

Pred zatvorením tiketu zapíšte, ktorú poruchu ste skutočne pozorovali. Chýbajúca interná odpoveď a dopyt unikajúci z tunela si žiadajú odlišné opravy a zmena prípony, ktorá opraví prvú, môže ticho zhoršiť druhú. Kto tiket prevezme ďalej, bude veriť označeniu, preto označenie urobte presným.