VPN-i DNS haarab iga päringu: paranda NetworkManageris dns-priority

Ühenda kontori VPN ja äkki läheb iga nimepäring ettevõtte resolverisse. Avalikud nimed lahenevad endiselt, nii et miski ei tundu katki, kuni kohaliku printeri nimi ebaõnnestub või split-horizon-kirje tagastab kontori aadressi. Mõnes Fedora seadistuses juhtub vastupidine: teenusepakkuja resolver vastab edasi ka pärast tunnelitõusu. Mõlemad on üks küsimus — milline resolver selle päringu omanik on — ja NetworkManageri süsteemides elab vastus iga ühenduse DNS-omadustes.

Kaks ühendust, üks võitev resolver

Iga ühendus deklareerib DNS-i prioriteedi. Tavalised ühendused on vaikimisi 50 ja VPN-ühendused 0 ning madalam väärtus võidab. Just see vaikeväärtus on põhjus, miks VPN-ühendus möödub vaikselt juhtmega ühendusest iga domeeni puhul, mida ta nõuab: null võidab viiskümmend, ilma et keegi seda valiks.

Prioriteet järjestab kandidaadid. See ei piira, mille kohta võitjalt küsitakse. Otsingudomeenita VPN-ühendus nõuab kõike, seega selle eelistamine saadab ka avalikud päringud tunnelisse ja split-tunnel-kujunduses sinna, kuhu ettevõtte resolver edasi suunab.

Prioriteet otsustab järjekorra, otsingunimekiri otsustab omandi

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

Otsingunimekiri on omandideklaratsioon. Paljas domeen nagu corp.example muutub otsingusufiksiks ja marsruutimisdomeeniks. Ainult marsruutimise vorm ~corp.example saadab selle sufiksi all olevad päringud sellele ühendusele, lisamata domeeni lühinimedele. See tilde on vahe sõnade „küsi sellelt serverilt“ ja „küsi sellelt serverilt ja lõpeta minu trükkimine“ vahel.

Kasuta mõlemat vormi, kui kasutajad trükivad lühikesi hostinimesid ja kirjeid adresseeritakse ka täielikult kvalifitseeritud nimedega. Kasuta ainult marsruutimisvormi, kui tahad jaotust ilma muutmata seda, kuidas resolver palja nime lõpule viib.

Seejärel tee eelistus selgesõnaliseks ja aktiveeri ühendus uuesti:

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"

Negatiivne prioriteet on dokumenteeritud viis öelda „eelista seda ühendust“, ja mõlema aadressiperekonna määramine hoiab käitumise ühtlasena IPv6-ühendusega hostis. Omaduse muutmine ilma ühendust uuesti aktiveerimata ei muuda midagi sellest, mis praegu töötab, seetõttu lõpeb jada selgesõnalise käsuga up.

Jäta jaotus systemd-resolvedi hoida

Vaikimisi dnsmasq-plugin koondab päringud ühte kohalikku resolverisse, seega jääb eraldamine lüli kaupa tömbiks. systemd-resolved toob jaotuse välja iga lüli kaupa ning resolvectl query nimetab lüli, mis vastas.

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

Pärast seda kannab ettevõtte lüli corp.example ja avalik resolver teenindab ülejäänut. Kui päring jõuab valele lülile, nimetab käsk lüli, mis sellele vastas, ja selle teadmine on parem kui ainult aadressi teadmine.

Sobita DNS-i kujundus tunnelitüübiga

Privaatsuskujundused, mis saadavad kõik läbi tunneli, ei peaks kandma jaotusnimekirja, sest see annaks avalikud nimed kohalikule resolverile tagasi ja tühistaks kavatsuse. Split-tunnel-kujundused vajavad seda: ilma selleta näeb ettevõtte resolver iga avalikku päringut ja seadistus laguneb hetkel, mil tunnel langeb.

Siis on kill switch, mis blokeerib DNS-i väljaspool tunnelit. Nimed lahenevad tunneli tsoonide jaoks ja ebaõnnestuvad kõikjal mujal, samal ajal kui ühendus on täiesti terve. Toimivad vastused on selgesõnaline luba LAN-i resolverile või kohalik vahemälu, mis edastab ainult ettevõtte tsooni, ja kumbki neist on erand, millel on omanik, mitte tunnelis olev defekt.

Profiil, mis kirjutab liidese käivitamisel resolveri konfiguratsiooni üle, käitub peaaegu samamoodi: kui kohalik resolver pole kättesaadav, lahenevad ainult nimed, mida tunnel teab. Ükskõik milline mehhanism kehtib, kirjuta üles, millised nimed peaksid igas olekus töötama, ja anna see nimekiri sellele, kes aruandeid menetleb.

Kontrolli lüli kaupa ja siis veel kord pärast uuesti ühendamist

Küsi üht sisemist ja üht avalikku nime ning vaata, kuhu päring tegelikult läheb. Lekkekontrolli leht ütleb, milline resolver vastas, mitte millise lüli süsteem valis, seega ei ütle see äsja seadistatud järjekorra kohta midagi.

Käivita kaks päringut uuesti pärast katkestamist ja uuesti ühendamist. Prioriteedid rakenduvad uuesti, kui ühendus aktiveerub, ja vana sümbollink võib üle elada uuenduse, mida keegi ei mäleta. Lõpuks tahad kirja panna, milline resolver mille sufiksi omanik on, pluss kontroll, mis kehtib ka homme.