DNS přes VPN přebírá každý dotaz: opravte dns-priority v NetworkManageru

Připojte firemní VPN a najednou každý dotaz na jméno míří na podnikový resolver. Veřejná jména se stále převádějí, takže nic nevypadá rozbité, dokud neselže jméno místní tiskárny nebo záznam split-horizon nevrátí adresu kanceláře. Na některých instalacích Fedory se děje opak: resolver poskytovatele odpovídá dál i po navázání tunelu. Obojí je jedna otázka — který resolver tento dotaz vlastní — a v systémech NetworkManager odpověď žije ve vlastnostech DNS jednotlivého připojení.

Dvě připojení, jeden vítězný resolver

Každé připojení deklaruje prioritu DNS. Běžná připojení mají ve výchozím nastavení 50 a připojení VPN 0, a vyhrává nižší hodnota. Právě proto připojení VPN tiše předčí kabelové pro každou doménu, kterou si nárokuje: nula poráží padesát, aniž by si to kdokoli vybral.

Priorita řadí kandidáty. Neomezuje, na co se vítěze ptáme. Připojení VPN bez vyhledávací domény si nárokuje vše, takže jeho upřednostnění posílá i veřejné dotazy do tunelu a při rozděleném tunelu tam, kam podnikový resolver přeposílá.

Priorita určuje pořadí, seznam hledání určuje vlastnictví

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Seznam hledání je prohlášení o vlastnictví. Holá doména jako corp.example se stane příponou hledání a směrovací doménou. Forma jen pro směrování ~corp.example posílá dotazy pod touto příponou tomuto připojení, aniž by k krátkým jménům přidávala doménu. Ta tilda je rozdíl mezi „zeptej se tohoto serveru“ a „zeptej se tohoto serveru a dokonči mi psaní“.

Obě formy použijte, když uživatelé píšou krátká jména hostitelů a záznamy se zároveň adresují plně kvalifikovanými jmény. Jen směrovací formu použijte, když chcete rozdělení bez změny toho, jak resolver doplňuje holé jméno.

Pak preferenci zviditelněte a připojení znovu aktivujte:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Záporná priorita je dokumentovaný způsob, jak říci „upřednostni toto připojení“, a nastavení pro obě rodiny adres udrží chování konzistentní na hostiteli s konektivitou IPv6. Změna vlastnosti bez opětovné aktivace připojení nezmění nic z toho, co právě běží, a proto sekvence končí explicitním up.

Nechte rozdělení na systemd-resolved

Výchozí plugin dnsmasq stahuje dotazy do jednoho místního resolveru, takže oddělení po spojích zůstává hrubé. systemd-resolved vystavuje rozdělení po každém spoji a resolvectl query pojmenuje spoj, který odpověděl.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Poté podnikový spoj nese corp.example a veřejný resolver obsluhuje zbytek. Když dotaz dorazí na nesprávný spoj, příkaz pojmenuje spoj, který na něj odpověděl, a vědět to je lepší než znát jen adresu.

Přizpůsobte návrh DNS typu tunelu

Návrhy pro soukromí, které posílají vše tunelem, by neměly mít seznam rozdělení, protože ten by vrátil veřejná jména místnímu resolveru a zrušil záměr. Návrhy s rozděleným tunelem ho potřebují: bez něj podnikový resolver vidí každý veřejný dotaz a nastavení se rozbije ve chvíli, kdy tunel spadne.

Pak je tu kill switch, který blokuje DNS mimo tunel. Jména se převádějí pro zóny tunelu a všude jinde selhávají, zatímco připojení je naprosto zdravé. Schůdné odpovědi jsou výslovné povolení pro místní resolver v LAN nebo místní cache, která přeposílá jen podnikovou zónu, a obojí je výjimka s vlastníkem, nikoli závada tunelu.

Profil, který při startu rozhraní přepisuje konfiguraci resolveru, se chová skoro stejně: jakmile je místní resolver nedostupný, převedou se jen jména, která tunel zná. Ať platí jakýkoli mechanismus, zapište, která jména mají v každém stavu fungovat, a ten seznam dejte tomu, kdo přijímá hlášení.

Ověřte po spojích a pak znovu po opětovném připojení

Zeptejte se na jedno interní a jedno veřejné jméno a sledujte, kam dotaz skutečně jde. Stránka pro kontrolu úniku vám řekne, který resolver odpověděl, ne který spoj systém zvolil, takže o pořadí, které jste právě nastavili, neříká nic.

Spusťte oba dotazy znovu po odpojení a opětovném připojení. Priority se znovu použijí při aktivaci připojení a starý symbolický odkaz může přežít upgrade, na který si nikdo nepamatuje. Na konci chcete mít zapsáno, který resolver vlastní kterou příponu, plus kontrolu, která platí i zítra.