Az OpenVPN DNS-e SIGKILL után is ott marad: először a tulajdonost ellenőrizze

A DNS leáll a feloldással, miután egy OpenVPN kliens folyamatát megölik, és az első ösztön az, hogy újraírják a /etc/resolv.conf fájlt. Ez a módosítás tönkretehet egy működő feloldót, miközben a valódi elavult állapot máshol van. Először azt a kérdést kell tisztázni, hogy ki birtokolja az alagút által telepített DNS-beállításokat, és hogy az a kilépés, amely kihagyta a takarítást, valóban számított-e.

Három feltétel dönti el a javítást: a folyamatot lezáró jelzés, a beállításokat fogadó feloldó komponens, és hogy létezik-e még az alagút kapcsolata. Ezekre ebben a sorrendben válaszoljon, és a javítás általában egy globális fájl érintése nélkül következik.

Döntse el, milyen kilépés történt

A Community kiadás OpenVPN változatában a SIGINT és a SIGTERM is szabályos kilépési kérés. A SIGKILL nem kapható el: sem blokkolni, sem kezelni nem lehet, ezért egyetlen leállítási rutin sem kap esélyt a futásra. A normál Ctrl+C egy előtérben futó terminálban SIGINT-et generál, míg a várakozást feladó felügyelő általában SIGKILL-re lép tovább. A különbség számít, mert csak a második eset garantálja, hogy a horgok kimaradtak.

A screen vagy tmux alatti futtatás nem változtat azon, hogy a Ctrl+C melyik jelzést küldi. Azt ellenőrizze, amit a folyamat ténylegesen kapott, ne azt, amit a terminál általában tesz.

Ha egy szolgáltatás vagy kapcsolatkezelő futtatja az alagutat, azt az egy kapcsolatot a tulajdonosán keresztül állítsa le, ne a pid megölésével. A kezelő újraindíthatja a folyamatot, így friss alagút és zavaros feloldóállapot marad. Egy önálló folyamatnak csak egy szokásos leállítási kérésre van szüksége, hogy a takarítás lefusson.

Döntse el, ki birtokolja a feloldót

A systemd-resolved, a resolvconf stílusú szkript és az egyszerű fájlátírás három különböző tulajdonos. Az első a kapcsolatonkénti beállításokat a memóriában tartja, és eldobja őket, amikor az interfész eltűnik. A második olyan rekordokat tart, amelyek addig maradnak, amíg valami el nem távolítja őket. A harmadik fájlt ír, és a helyreállítást arra hagyja, aki írta.

Azonosítsa a tulajdonost, mielőtt javító parancsot választ. Ugyanannak a tünetnek három különböző helyes válasza van attól függően, melyik van használatban.

Egy NetworkManager által kezelt VPN már birtokolhatja a feloldó változtatásait. Egy második segítő ráhelyezése két tulajdonost hoz létre, akik ugyanazért a kapcsolatért versengenek, és a vesztes állapota a következő újracsatlakozáskor újra megjelenik. Ha egy kezelő illetékes, a beállítást a kezelőben javítsa, ne egy szkriptben.

Mit tud és mit nem tud a down horog

A szkript down egyszer fut le, miután a TUN/TAP eszköz bezárult. A down-pre hozzáadása megfordítja ezt a sorrendet, és a szkriptet még az eszköz létezése közben futtatja, amit az élő kapcsolatot igénylő segítők megkövetelnek.

Egyik irányelv sem éri el, hogy egy horog a SIGKILL után lefusson. A jogosultságokat sem állítja vissza a down-pre: ha a démon egy user vagy group szintjére süllyed, vagy belép egy chroot környezetbe, a horog azzal a hozzáféréssel fut, amit ez neki hagy. Egy meghívott horog továbbra is meghiúsulhat a feloldó frissítésében. Az OpenVPN referenciája a jelzéseket és a visszahívás életciklusát tárgyalja.

Ellenőrizze a horog saját hibáját a folyamat kilépési állapota mellett. A hiányzó takarítás és a sikertelen takarítás ugyanúgy néz ki a feloldóban, és másképp a naplókban.

Ellenőrizze, milyen állapot maradt valójában

Egy systemd-resolved-et használó rendszeren a resolvectl status megmutatja, melyik kapcsolat hordozza még a VPN DNS-kiszolgálóit vagy az útválasztási tartományokat. Az a kapcsolat tartozhat egy már megszűnt összeköttetéshez, vagy egy másik, még élő alagúthoz.

Az eltűnő interfész magával viszi a kapcsolatonkénti konfigurációját, így egy kihagyott horog tiszta DNS mellett is fennállhat. Ha a kapcsolat még regisztrálva van, és kizárólag a leállított összeköttetés birtokolja, a tulajdonos kezelőnek el kell távolítania. Ha egy régebbi szkript átírt egy globális feloldófájlt, inkább annak a szkriptnek a dokumentált helyreállítási lépését keresse.

Állítsa helyre anélkül, hogy ellopna egy másik kapcsolatot

Amikor a kapcsolatonkénti beállítások az Ön kezelésében vannak, a resolvectl revert veszi a kapcsolat nevét, és törli az adott interfész futásidejű DNS-konfigurációját. Ez futásidejű művelet, nem profil szerkesztése, ezért a tartós kapcsolatkonfiguráció érintetlen marad. Ha rossz kapcsolatot nevez meg, törli egy működő alagút DNS-ét, ezért a név a státuszkimenetből származik.

Erősítse meg, hogy a /etc/resolv.conf kezelt szimbolikus hivatkozás, mielőtt szerkesztené, majd állítsa le a klienst még egyszer a szokásos módon, és nézze meg újra a DNS-t. Ha a második leállítás rendbe tesz, a korábbi probléma a kényszerített kilépés volt, nem a konfiguráció.