A VPN DNS-e minden lekérdezést átvesz: javítsd a dns-priority beállítást a NetworkManagerben

Csatlakozz az irodai VPN-hez, és hirtelen minden névfeloldás a vállalati resolverhez megy. A nyilvános nevek továbbra is feloldódnak, ezért semmi sem tűnik töröttnek, amíg egy helyi nyomtató neve meg nem hibázik, vagy egy split-horizon rekord vissza nem adja az iroda címét. Néhány Fedora-telepítésen az ellenkezője történik: a szolgáltató resolvere az alagút felállása után is válaszol. Mindkettő egyetlen kérdés — melyik resolver birtokolja ezt a lekérdezést —, és a NetworkManager rendszereken a válasz az egyes kapcsolatok DNS-tulajdonságaiban él.

Két kapcsolat, egy nyertes resolver

Minden kapcsolat megad egy DNS-prioritást. A közönséges kapcsolatok alapértelmezésben 50-en, a VPN-kapcsolatok 0-n állnak, és az alacsonyabb érték nyer. Pont ez az alapértelmezés az oka, hogy a VPN-kapcsolat csendben megelőzi a vezetékes kapcsolatot minden domainnél, amelyre igényt tart: a nulla legyőzi az ötvenet anélkül, hogy bárki úgy döntött volna.

A prioritás sorba rendezi a jelölteket. Nem korlátozza, hogy mit kérdezünk a győztestől. A keresési domain nélküli VPN-kapcsolat mindenre igényt tart, így előnyben részesítése a nyilvános lekérdezéseket is az alagútba küldi, és osztott alagút kialakításánál oda, ahová a vállalati resolver továbbít.

A prioritás dönt a sorrendről, a keresési lista a tulajdonról

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

A keresési lista a tulajdon nyilatkozata. Egy csupasz domain, például a corp.example, keresési utótaggá és útválasztási domainné válik. A csak útválasztásra szolgáló forma, a ~corp.example, az utótag alatti lekérdezéseket ehhez a kapcsolathoz küldi anélkül, hogy a domaint a rövid nevekhez fűzné. Az a tilde a különbség a „kérdezd ezt a szervert” és a „kérdezd ezt a szervert, és fejezd be helyettem a gépelést” között.

Mindkét formát használd, amikor a felhasználók rövid gazdagépneveket írnak, és a rekordok teljesen minősített nevekkel is címezhetők. Csak az útválasztási formát használd, ha a felosztást szeretnéd anélkül, hogy megváltoztatnád, hogyan egészít ki a resolver egy csupasz nevet.

Ezután tedd egyértelművé a preferenciát, és aktiváld újra:

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"

A negatív prioritás a dokumentált módja annak, hogy azt mondjuk: „részesítsd előnyben ezt a kapcsolatot”, és mindkét címcsalád beállítása egységessé teszi a viselkedést egy IPv6-kapcsolattal rendelkező gazdagépen. A tulajdonság módosítása a kapcsolat újraaktiválása nélkül semmin sem változtat, ami most fut, ezért a sorozat egy kifejezett up paranccsal végződik.

Hagyd, hogy a systemd-resolved tartsa a felosztást

Az alapértelmezett dnsmasq bővítmény egyetlen helyi resolverbe tereli a lekérdezéseket, így a kapcsolatonkénti elkülönítés durva marad. A systemd-resolved kapcsolatonként teszi láthatóvá a felosztást, és a resolvectl query megnevezi a válaszoló kapcsolatot.

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

Ezután a vállalati kapcsolat viszi a corp.example címet, a maradékot pedig egy nyilvános resolver szolgálja ki. Amikor egy lekérdezés a rossz kapcsolatra jut, a parancs megnevezi azt a kapcsolatot, amely válaszolt rá, és ezt tudni jobb, mint csak a címet ismerni.

Illeszd a DNS-tervet az alagút típusához

Azok a magánéleti megoldások, amelyek mindent az alagúton küldenek, ne hordozzanak felosztási listát, mert az visszaadná a nyilvános neveket a helyi resolvernek, és meghiúsítaná a szándékot. Az osztott alagút megoldásainak kell egy: nélküle a vállalati resolver minden nyilvános lekérdezést lát, és a beállítás abban a pillanatban elromlik, amikor az alagút leesik.

Aztán ott van a kill switch, amely blokkolja az alagúton kívüli DNS-t. A nevek az alagút zónáihoz oldódnak fel, és mindenhol máshol meghiúsulnak, miközben a kapcsolat teljesen egészséges. A járható válaszok a LAN resolverének adott kifejezett engedély vagy egy helyi gyorsítótár, amely csak a vállalati zónát továbbítja, és mindkettő tulajdonossal rendelkező kivétel, nem hiba az alagútban.

Az a profil, amely a felület indulásakor átírja a resolver konfigurációját, nagyjából ugyanígy viselkedik: amint a helyi resolver elérhetetlenné válik, csak azok a nevek oldódnak fel, amelyeket az alagút ismer. Bármelyik mechanizmus érvényes, írd le, mely neveknek kell működniük az egyes állapotokban, és add át azt a listát annak, aki a bejelentéseket kezeli.

Ellenőrizd kapcsolatonként, majd újracsatlakozás után ismét

Kérdezz meg egy belső és egy nyilvános nevet, és figyeld, hová megy valójában a lekérdezés. Egy szivárgásellenőrző oldal megmondja, melyik resolver válaszolt, nem azt, melyik kapcsolatot választotta a rendszer, tehát semmit sem mond az imént beállított sorrendről.

Futtasd újra a két lekérdezést leválasztás és újracsatlakozás után. A prioritások újra érvénybe lépnek, amikor egy kapcsolat aktiválódik, és egy régi szimbolikus link túlélhet egy olyan frissítést, amelyre senki sem emlékszik. Amit a végén rögzíteni szeretnél, az az, hogy melyik resolver melyik utótagot birtokolja, plusz egy ellenőrzés, amely holnap is érvényes.