A resolv.conf szerkesztése nem javítja a DNS-t a VPN leválasztása után

Leválasztja a VPN-t, a ping 1.1.1.1 még válaszol, és minden névfeloldás megakad, mire az oldal végül feladja. Aztán a cat /etc/resolv.conf olyan névszolgáltatót mutat, amely valaha csak az alagúton belül létezett, rendszerint a lista első helyén. A sor törlése úgy tűnik, mintegy tíz percre megoldja, amíg egy felfüggesztés, egy Wi-Fi-vándorlás vagy egy újraindítás vissza nem teszi. A fájl, amelyet szerkesztett, nem a beállítás; hanem a kapcsolat állapotának megjelenítése, amely más összetevő tulajdona.

Miért kerül másodpercekbe egyetlen elavult bejegyzés minden lekérdezésnél

A glibc feloldója sorrendben járja végig a névszolgáltatók listáját, és megvárja egy időtúllépés leteltét, mielőtt a következőt próbálná, a resolv.conf(5) pedig három bejegyzésre korlátozza ezt a listát. Tegyen egy alagút oldali feloldót, például 10.8.0.1-et a lista elejére, miután az alagút eltűnt, és minden lekérdezés kifizeti az időtúllépést, mielőtt átesne egy válaszoló kiszolgálóra. Ezért tűnik a tünet halott kapcsolatnak és nem DNS-hibának: a böngészők blokkolnak, lejár az idejük, és néha egy gyorsítótárazott címet szolgálnak ki, amely később elavul.

Ez azt is megmagyarázza, miért „az internet elromlott” formában érkezik a panasz. Egy IP-címre küldött ping bizonyítja, hogy a kapcsolat rendben van, amitől a hiba az alkalmazás hibájának tűnik. A feloldók listája az első dolog, amit el kell olvasni, és az utolsó, amit szerkeszteni kell.

A mítosz: a resolv.conf beállításfájl

Kérdezze meg, mi is valójában az útvonal, mielőtt megváltoztatja:

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

systemd-resolved gazdagépen szimbolikus hivatkozás egy stub fájlra, amely a 127.0.0.53-ra mutat, és a valódi kiszolgálók abban a kapcsolatonkénti állapotban élnek, amelyet a resolvectl kiír. NetworkManager gazdagépen lehet egy fájl, amelyet a NetworkManager az aktív kapcsolatból ír. Egyes gyártói klienseknél egyszerű fájl, amelyet csatlakozáskor a helyén újraírnak, és ha nincs szerencséje, leválasztáskor soha nem állítanak vissza. Ez három különböző tulajdonos, és az első kettő kézi szerkesztése vagy semmit nem tesz, vagy a következő hálózati eseményig tart.

A resolvectl status az a nézet, amely az igazat mondja: kapcsolatonkénti DNS-kiszolgálók, útválasztási tartományok, és hogy létezik-e még az alagút kapcsolata. A resolvectl query example.com tovább megy, és megmutatja, melyik interfész válaszolt. Használja mindkettőt, mielőtt fájlhoz nyúl, és tartsa észben, hogy a saját biztonságos DNS-sel rendelkező böngésző mindezt figyelmen kívül hagyja.

Találja meg a tulajdonost, mielőtt bármit szerkeszt

Általában három összetevő verseng ugyanazért a beállításért: a systemd-resolved, a NetworkManager és amit a VPN-kliens telepített. Először azonosítsa az élőt:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Ha a resolved aktív, és a szimbolikus hivatkozás a stubjára mutat, a globális fájl generált kimenet, és a szerkesztése kozmetikai. Ha a NetworkManager birtokolja a kapcsolatot, a kiszolgálók a kapcsolatprofilhoz tartoznak, tehát a javítás nmcli-tulajdonság módosítása, nem fájlszerkesztés. Ha gyártói démon fut, csak a saját visszaállítási útvonala éli túl a következő csatlakozást.

Tisztítsa meg a kapcsolat állapotát, amelyet a kliens hátrahagyott

Egy megölt kliens nem tudja lefuttatni a takarító kampóját. A SIGKILL egyáltalán nem fogható el, a SIGINT és a SIGTERM viszont igen, ezért az erőszakos ölés után „csak leállt” alagút gyakran a helyén hagyja az interfész regisztrációját és a feloldó bejegyzését is. Keresse meg a konkrét PID-et, és csak annak küldje a jelet:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Ne nyúljon a pkill -f vpn vagy a killall vpn parancshoz, amíg el nem olvasta a teljes találati listát. A -f a teljes parancssorra illeszkedik, így leállíthat egy burkolószkriptet, egy szerkesztő munkamenetet vagy egy olyan független folyamatot, amelynek útvonala tartalmazza a karakterláncot. A rossz folyamat munka közbeni leállítása az, ahogy egy feloldóproblémából elveszett fájl lesz.

A resolvectl revert visszaállítja az adott kapcsolat futásidejű DNS-konfigurációját, ami szűkebb a feloldó újraindításánál és sokkal szűkebb a globális fájl szerkesztésénél. Ha az alagút kapcsolata teljesen eltűnt, a systemctl restart NetworkManager újraépíti a kapcsolat állapotát, és ez az a lépés, amelyhez a forrás-szálak újra meg újra visszatérnek. Figyeljen a Restart=always beállítású szolgáltatáskezelőre, mert az egy megölt klienst és annak DNS-beállításait egyenesen visszateheti.

A másik irány: betolt DNS, amely soha nem érkezett meg

Az elavult bejegyzés tükörképe egy alagút minden használható feloldó nélkül. A profilban lévő DNS-beállítás kérés; a kapcsolatot kezelő összetevőnek át kell adnia a feloldónak. Ha a napló azt mutatja, hogy a kiszolgáló megérkezett, de az alagút kapcsolata nem hordoz DNS-beállítást, akkor az integráció hiányzik, nem a kiszolgáló.

Tesztelje az átadást kézi végrehajtással, ami elválasztja a „rossz a kiszolgáló” és a „senki nem alkalmazta” esetét:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

A mindent elkapó útválasztási tartomány minden nevet arra a kapcsolatra küld, amit egy teljes alagút kliens kíván, és amit a megosztott DNS nem használhat. Ezek a beállítások eltűnnek a következő csatlakozáskor. Ha tartósan szeretné őket a NetworkManagerben, kapcsolja ki az automatikus DNS-t, állítsa be a kiszolgálót a kapcsolaton, és adja hozzá a tartományt:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Egy vállalati alagúthoz, amelynek csak belső nevekre szabad válaszolnia, sorolja fel ezeket a zónákat kezdő tildével a mindent elkapó helyett, hogy a nyilvános nevek továbbra is a helyi feloldót használják.

Megkerülő megoldások, amelyek a következő kiesés lesznek

A resolv.conf csatlakozás előtti másolása és utáni visszaállítása legitim sor egy runbookban, és megkerülő megoldás, nem javítás. Pontosan akkor vall kudarcot, amikor számít, mert egy összeomlás vagy egy kényszerű újraindítás kihagyja a visszaállítást. Írja le megkerülő megoldásként, hogy a következő ember ne építsen rá.

A systemd-resolved kikapcsolása és nyilvános kiszolgálók kemény kódolása a másik népszerű lépés. Kiszámíthatóvá teszi a csatlakozást és a leválasztást, és minden más hálózat számára eltávolítja a kapcsolatonkénti DNS-t, ami elrontja a belső nevek megosztott DNS-ét, és meghiúsítja egy olyan alagút célját, amely a lekérdezéseket bent kívánja tartani. A resolvconf telepítése és a nyilvános kiszolgálók rögzítése ugyanannyiba kerül egy plusz réteggel. Tekintse bármelyiket diagnózisnak: ha visszahozza a böngészést, megtanulta, hogy a feloldóintegráció a hibás, nem azt, hogy a nyilvános kiszolgálók helyesek.

A tartós javítás rétegenként egy tulajdonos: döntse el, melyik összetevő birtokolja az alagút kapcsolatának DNS-ét és melyik a globális alapértelmezést, írja le, és távolítsa el a többit az útvonalról. Ezután leválasztás után ellenőrizze egy olyan névvel, amelyet csak a VPN old fel. Ha egy privát név még válaszol, a regisztrációt nem távolították el; ha semmi nem oldódik fel, a fájl egy már nem létező kiszolgálóra mutat. Mindkettő látható a resolvectlben, mielőtt böngészőt nyit.