VPN DNS preuzima svako traženje: popravite dns-priority u NetworkManageru

Povežite uredski VPN i odjednom svako traženje imena ide na korporativni resolver. Javna imena se još razrješavaju, pa ništa ne izgleda pokvareno dok ne padne ime lokalnog pisača ili split-horizon zapis ne vrati uredsku adresu. Na nekim Fedora postavkama događa se suprotno: ISP-ov resolver nastavlja odgovarati i nakon što je tunel podignut. Obje su jedno pitanje — koji resolver posjeduje ovaj upit — a na NetworkManager sustavima odgovor živi u DNS svojstvima pojedine veze.

Dvije veze, jedan resolver pobjednik

Svaka veza navodi DNS prioritet. Obične veze prema zadanim postavkama imaju 50, a VPN veze 0, i pobjeđuje niža vrijednost. Upravo zato VPN veza tiho nadjačava žičanu za svaku domenu koju prisvaja: nula pobjeđuje pedeset bez toga da ju je itko odabrao.

Prioritet poreda kandidate. On ne ograničava o čemu se pobjednika pita. VPN veza bez domene pretraživanja prisvaja sve, pa njeno preferiranje šalje i javne upite u tunel, a u split-tunnel dizajnu i onamo kamo korporativni resolver prosljeđuje.

Prioritet odlučuje red, popis pretraživanja odlučuje vlasništvo

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

Popis pretraživanja je izjava o vlasništvu. Gola domena poput corp.example postaje sufiks pretraživanja i routing domena. Oblik samo za routing ~corp.example šalje upite pod tim sufiksom na ovu vezu bez dodavanja domene kratkim imenima. Ta tilda je razlika između „pitaj ovaj poslužitelj“ i „pitaj ovaj poslužitelj i dovrši moje tipkanje“.

Upotrijebite oba oblika kad korisnici tipkaju kratka imena hostova, a zapisi se adresiraju i punim kvalificiranim imenima. Upotrijebite samo routing oblik kad želite podjelu bez promjene načina na koji resolver dovršava golo ime.

Zatim učinite preferenciju izričitom i ponovno aktivirajte:

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"

Negativan prioritet je dokumentirani način da kažete „preferiraj ovu vezu“, a postavljanje za obje obitelji adresa čuva ponašanje dosljednim na hostu s IPv6 povezivošću. Promjena svojstva bez ponovnog aktiviranja veze ne mijenja ništa što trenutačno radi, zato slijed završava izričitom naredbom up.

Pustite systemd-resolved da drži podjelu

Zadani dnsmasq dodatak slijeva upite u jedan lokalni resolver, pa podjela po poveznici ostaje gruba. systemd-resolved izlaže podjelu po poveznici, a resolvectl query imenuje poveznicu koja je odgovorila.

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

Nakon toga korporativna poveznica nosi corp.example, a javni resolver poslužuje ostalo. Kad upit stigne na pogrešnu poveznicu, naredba imenuje poveznicu koja je na njega odgovorila, a znati to bolje je od samog znanja adrese.

Uskladite DNS dizajn s vrstom tunela

Dizajni privatnosti koji sve šalju kroz tunel ne bi smjeli nositi popis podjele, jer bi on vratio javna imena lokalnom resolveru i poništio namjeru. Split-tunnel dizajni ga trebaju: bez njega korporativni resolver vidi svaki javni upit, a postavka se slomi u trenutku kad tunel padne.

Zatim je tu kill switch koji blokira DNS izvan tunela. Imena se razrješavaju za zone tunela i padaju svugdje drugdje dok je veza potpuno zdrava. Izvediva rješenja su izričito dopuštenje za LAN resolver ili lokalni cache koji prosljeđuje samo korporativnu zonu, a oboje je iznimka s vlasnikom, a ne kvar u tunelu.

Profil koji prepisuje konfiguraciju resolvera pri pokretanju sučelja ponaša se gotovo jednako: kad lokalni resolver postane nedostupan, razrješavat će se samo imena koja tunel poznaje. Koji god mehanizam vrijedi, zapišite koja imena trebaju raditi u kojem stanju i dajte taj popis onome tko prima prijave.

Provjerite po poveznici, pa ponovno nakon ponovnog spajanja

Pitajte jedno interno i jedno javno ime i gledajte kamo upit zapravo ide. Stranica za provjeru curenja kaže koji je resolver odgovorio, a ne koju je poveznicu sustav odabrao, pa ne govori ništa o redoslijedu koji ste upravo postavili.

Pokrenite dva upita ponovno nakon prekida i ponovnog spajanja. Prioriteti se ponovno primjenjuju kad se veza aktivira, a stara simbolička poveznica može nadživjeti nadogradnju koje se nitko ne sjeća. Ono što na kraju želite zapisati jest koji resolver posjeduje koji sufiks, uz provjeru koja vrijedi i sutra.