Állítsa le két Linux-szolgáltatás versengését az /etc/resolv.confért

A DNS újra és újra visszaáll, a VPN újracsatlakozása visszavonja a javítását, és végül valaki a csapatban javasolja a fájl zárolását. Ez a sorrend tünet, nem megoldás: két komponens egyaránt azt hiszi, hogy övé /etc/resolv.conf, és az utoljára író nyer. A fájl zárolása nem oldja meg a tulajdonjogi ütközést, csak elrejti, miközben éppen azt a komponenst töri el, amelyet valójában szeretett volna. Végezze el az alábbi négy ellenőrzést sorrendben, és a tulajdonos szintjén javítsa a felállást, ne a fájlnál.

Ellenőrzés 1: szimbolikus link-e, és hová mutat

Kezdje magával a fájllal, mert lehet, hogy az általa szerkesztett útvonal egyáltalán nem fájl. A feloldó futásidejű könyvtárába mutató szimbolikus link teljesen máshogy viselkedik, mint egy egyszerű fájl, amelyet egy kliensszkript újraír:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

A systemd-resolved stub-útvonalára mutató link azt jelenti, hogy a fájl tartalma generálódik, és a kézi szerkesztést a következő esemény felülírja. Az egyszerű, nameserver-sorokat tartalmazó fájlt általában az a kliens vagy DHCP-hook írja, amely csatlakozáskor fut. Mindkettő legitim; az a fontos, hogy tudja, melyik van Önnél, mielőtt bármit megváltoztat.

Ellenőrzés 2: melyik démon fut

Derítse ki, mi aktív valójában, ne azt, mi van telepítve. Egy modern disztribúción több feloldó is jelen lehet, és az válaszol, amelyik az 53-as portot tartja a loopback interfészen:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

A státuszkimenet megnevezi a kapcsolatonkénti DNS-kiszolgálókat és az útválasztási tartományokat, ez pedig az a térkép, amelyre a split DNS-hez szüksége van. Ha a belső neveknek belső kiszolgálóra kell menniük, minden másnak pedig nyilvánosra, ez a szabályzat a kapcsolatonkénti tartományokban él, és ha statikus nameserver-listává lapítja a fájlban, az különbség csendben elvész.

A NetworkManager saját konfigurációja dönti el, melyik háttérrendszert használja. A fő konfigurációs fájlban lévő dns= beállítása választ a belső feloldója, a dnsmasq, a systemd-resolved és a none között, és előfordulhat, hogy a disztribúció választott Ön helyett. Olvassa el ezt a beállítást, mielőtt eldönti, mit jelent a „DNS javítása” ezen a gépen.

Ellenőrzés 3: mit írhat a VPN-kliens

Itt él általában az ütközés. Az a VPN-kliens, amely közvetlenül újraírja a feloldó fájlját, harcba száll minden olyan szolgáltatással, amely szintén karbantartja, és az veszít, aki előbb fut. Az újabb OpenVPN-kiadások átadhatják a DNS-beállításokat a systemd-resolvednek a fájl újraírása helyett, ez az az együttműködő viselkedés, amelyet szeretne; a régebbi szkriptek és a kézzel írt hookok gyakran egy elavult segédprogramot hívnak, vagy egyszerűen felülírják a fájlt.

A WireGuard helyzete formailag hasonló: maga az interfész-konfiguráció nem kezeli a DNS-t, azt a körülötte lévő eszközök teszik, feloldó-segéden vagy a resolved-integráción keresztül. Ha két ilyen segéd van telepítve, mindkettő megpróbálja érvényesíteni a világképét csatlakozáskor.

Olvassa el a kliens up és down hookjait, ahelyett hogy találgatna. Néhány sor shell az /etc/openvpn/up.sh fájlban vagy egy ezzel egyenértékű könyvtárban megmagyarázza azt a viselkedést, amely egyébként véletlenszerűnek tűnik, és itt tudja rávenni a klienst az együttműködésre a versengés helyett.

Ellenőrzés 4: a tulajdonosnál javítsa, ne a fájlnál

Ha tudja, ki a tulajdonos, a DNS-t az adott tulajdonos által támogatott felületen keresztül konfigurálja. A systemd-resolved esetében ez kapcsolatonkénti beállításokat és útválasztási tartományokat jelent statikus fájl helyett; a NetworkManager esetében a kapcsolatiprofil DNS-beállításait és a választott háttérrendszert; a resolvconf-integrációt használó disztribúció esetében pedig az adott segéden keresztüli írást.

Ne tegye a fájlt változtathatatlanná. A változtathatatlanság attribútum leállítja a jogszerű DHCP-megújításokat és a VPN-frissítéseket együtt azokkal, amelyek ellen harcolt, és olyan állapotban hagyja a rendszert, amelyben a következő csomagfrissítés vagy újracsatlakozás olyan hibát produkál, amelyet senki sem tud a konfigurációból megmagyarázni. Elrejti a tulajdonjogi ütközést, ami pontosan az, amit meg próbált oldani.

Ahol két komponensnek valóban együtt kell léteznie, adjon nekik különböző feladatokat. Hagyja, hogy a hálózatkezelő birtokolja az interfészszintű konfigurációt, hagyja, hogy a VPN-kliens ugyanazon integráción keresztül kapcsolatonkénti DNS-t és tartományokat adjon hozzá, és távolítsa el a harmadik szkriptet, amely közvetlenül írja a fájlt. A systemd-resolved dokumentációja ismerteti a támogatott módokat és azt, hogy melyik mit tesz láthatóvá a /etc/resolv.conf fájlban. Válassza azt a módot, amely megfelel a megtartandó szabályzat mennyiségének. Ha a split DNS fontos, a kapcsolatonkénti tartományokkal működő stub-elrendezés megőrzi, míg az upstream kiszolgálókat a fájlba másoló mód csendben ellapítja.

Újracsatlakozás után ellenőrizze, ne a szerkesztés után

Az a fájl, amely közvetlenül a módosítás után helyesnek tűnik, semmit sem bizonyít, mert a következő esemény még nem történt meg. Indítsa el azt a sorozatot, amely korábban elrontotta: engedje le és hozza fel az alagutat, újítsa meg a DHCP-bérletet, vagy kapcsolja át az interfészt, majd olvassa újra ugyanazokat az értékeket.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

Aztán erősítse meg a lényeges különbséget: a belső név a belső kiszolgálón keresztül oldódik fel, míg a nyilvános név továbbra is működik. Az a konfiguráció, amely mindent a belső kiszolgálóra küld, jól néz ki, amíg valaki meg nem próbál az alagúton keresztül elérni az internetet, és az a konfiguráció, amely mindent a nyilvánosra küld, kiszivárogtatja a belső neveket.

Jegyezze fel a tulajdonost, a háttérrendszert és a szimbolikus link módját az üzembe helyezési megjegyzésekben. Ez az egy bekezdés a jövőbeli csomagfrissítést incidensből ellenőrzési ponttá változtatja, és megakadályozza, hogy a következő ember ugyanazt az ütközést újra felfedezze egy chattr paranccsal.