DNS cez VPN preberá každú požiadavku: opravte dns-priority v NetworkManageri

Pripojte firemné VPN a zrazu každá požiadavka na meno ide na podnikový resolver. Verejné mená sa stále prekladajú, takže nič nevyzerá pokazené, kým nezlyhá meno lokálnej tlačiarne alebo záznam split-horizon nevráti adresu kancelárie. Na niektorých inštaláciách Fedory sa deje opak: resolver poskytovateľa odpovedá ďalej aj po nadvihnutí tunela. Oboje je jedna otázka — ktorý resolver vlastní túto požiadavku — a v systémoch NetworkManager odpoveď žije vo vlastnostiach DNS jednotlivého pripojenia.

Dve pripojenia, jeden víťazný resolver

Každé pripojenie deklaruje prioritu DNS. Bežné pripojenia majú predvolene 50 a pripojenia VPN 0, a vyhráva nižšia hodnota. Práve preto pripojenie VPN potichu predbehne káblové pripojenie pre každú doménu, na ktorú si nárokuje: nula poráža päťdesiat bez toho, aby si to niekto vybral.

Priorita zoraďuje kandidátov. Neobmedzuje, na čo sa víťaza pýtame. Pripojenie VPN bez vyhľadávacej domény si nárokuje všetko, takže jeho uprednostnenie posiela aj verejné požiadavky do tunela a pri rozdelenom tuneli tam, kam podnikový resolver preposiela.

Priorita určuje poradie, zoznam vyhľadávania vlastníctvo

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

Zoznam vyhľadávania je vyhlásenie o vlastníctve. Holá doména ako corp.example sa stane príponou vyhľadávania a smerovacou doménou. Forma iba na smerovanie ~corp.example posiela požiadavky pod touto príponou tomuto pripojeniu bez pridania domény ku krátkym menám. Tá vlna je rozdiel medzi „spýtaj sa tohto servera“ a „spýtaj sa tohto servera a dokonči mi písanie“.

Použite obe formy, keď používatelia píšu krátke mená hostiteľov a záznamy sa adresujú aj plne kvalifikovanými menami. Iba smerovaciu formu použite, keď chcete rozdelenie bez zmeny toho, ako resolver dopĺňa holé meno.

Potom urobte preferenciu jednoznačnou a pripojenie znova 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 zdokumentovaný spôsob, ako povedať „uprednostni toto pripojenie“, a nastavenie oboch rodín adries udrží správanie konzistentné na hostiteľovi s pripojením IPv6. Zmena vlastnosti bez opätovnej aktivácie pripojenia nezmení nič z toho, čo práve beží, preto sa postup končí výslovným up.

Nechajte rozdelenie na systemd-resolved

Predvolený doplnok dnsmasq stiahne požiadavky do jedného lokálneho resolvera, takže oddelenie po spojeniach zostáva hrubé. systemd-resolved zverejňuje rozdelenie po spojeniach a resolvectl query pomenuje spojenie, ktoré odpovedalo.

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

Potom podnikové spojenie nesie corp.example a verejný resolver obsluhuje zvyšok. Keď požiadavka dorazí na nesprávne spojenie, príkaz pomenuje spojenie, ktoré naň odpovedalo, a vedieť to je lepšie ako poznať iba adresu.

Prispôsobte návrh DNS typu tunela

Návrhy pre súkromie, ktoré posielajú všetko tunelom, by nemali mať zoznam rozdelenia, pretože ten by vrátil verejné mená lokálnemu resolveru a zrušil zámer. Návrhy s rozdeleným tunelom ho potrebujú: bez neho podnikový resolver vidí každú verejnú požiadavku a nastavenie sa pokazí v okamihu, keď tunel padne.

Potom je tu kill switch, ktorý blokuje DNS mimo tunela. Mená sa prekladajú pre zóny tunela a všade inde zlyhávajú, hoci pripojenie je úplne zdravé. Schodné odpovede sú výslovné povolenie pre lokálny resolver v LAN alebo lokálna vyrovnávacia pamäť, ktorá preposiela iba podnikovú zónu, a oboje je výnimka s vlastníkom, nie porucha tunela.

Profil, ktorý pri štarte rozhrania prepisuje konfiguráciu resolvera, sa správa takmer rovnako: keď je lokálny resolver nedostupný, preložia sa iba mená, ktoré tunel pozná. Bez ohľadu na to, ktorý mechanizmus platí, zapíšte, ktoré mená majú v ktorom stave fungovať, a ten zoznam dajte tomu, kto spracúva hlásenia.

Overte po spojeniach a potom znova po opätovnom pripojení

Spýtajte sa na jedno interné a jedno verejné meno a sledujte, kam požiadavka skutočne ide. Stránka kontroly únikov vám povie, ktorý resolver odpovedal, nie ktoré spojenie systém vybral, takže o poradí, ktoré ste práve nastavili, nehovorí nič.

Spustite obe požiadavky znova po odpojení a opätovnom pripojení. Priority sa znova uplatnia pri aktivácii pripojenia a starý symbolický odkaz môže prežiť aktualizáciu, na ktorú si nikto nespomína. Na konci chcete mať zapísané, ktorý resolver vlastní ktorú príponu, plus kontrolu, ktorá bude platiť aj zajtra.