Pořadí záznamů v Debian resolvconf: dejte záznam VPN na první místo
Názevový server VPN neustále padá pod ten síťový, protože resolvconf řadí názvy záznamů. Upravte interface-order, znovu vygenerujte a ověřte dva dotazy.
Názevový server VPN neustále končí pod tím v LAN a úprava /etc/resolv.conf to spraví na pár minut. Tento soubor se generuje, takže oprava nikdy nevydrží. V debianském resolvconf je vstupem pro pořadí /etc/resolvconf/interface-order a ten řadí názvy záznamů, nikoli adresy DNS. Než sáhnete na kterýkoli ze dvou souborů, ověřte, který zásobník překladu jmen je skutečně nadřízený.
Ověřte, že výstup vlastní resolvconf
Začněte otázkou, co aktuální soubor zapsalo a co ho zapíše znovu. Balíček resolvconf se popisuje jako rámec pro dynamickou konfiguraci překladače a hostitel se systemd-resolved nebo překladačem spravovaným NetworkManagerem může zvenčí vypadat podobně, ale používat úplně jinou politiku.
readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1
Pokud přeložená cesta nevede do běhového adresáře resolvconf, zastavte se zde: tento návod patří jinému zásobníku.
Teprve po této kontrole má smysl vypsat záznamy, které resolvconf právě drží.
Přečtěte si záznamy dřív, než začnete psát vzory
interface-order porovnává názvy záznamů dodavatele, ne adresy a ne názvy rozhraní jádra. Vypište, co je zaregistrováno, aby vaše vzory odkazovaly na existující položky.
ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order
Název záznamu obvykle nese příponu určující jeho dodavatele, takže záznam tunelu a záznam DHCP mohou sdílet předponu rozhraní a přesto se řadit jinak. Zkopírujte přesné názvy z výpisu adresáře. Neodvozujte název z názvu rozhraní, protože o tom, co se zaregistruje, rozhoduje integrace klienta. Vymyšlený název nikdy nesedne a záznam propadne vzoru, který chytá vše, aniž by přišla jakákoli chybová zpráva.
Zapište pořadí jako vzory prvního výskytu
Soubor je seznam vzorů shell glob, jeden na řádek. Záznam zaujme pozici prvního vzoru, kterému odpovídá, takže široký vzor nad konkrétním činí konkrétní řádek nedostupným.
# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*
Umístěte konkrétní vzor tunelu nad vzor, který chytá vše, a nad vzor fyzického rozhraní.
Zachovejte ostatní řádky, které soubor už měl. Nahrazení celé politiky příkladem je způsob, jak se nesouvisející dodavatelé tiše přesouvají; změňte jeden řádek, znovu vygenerujte a porovnejte. Vzory nesmějí obsahovat mezery, lomítka ani úvodní tečku nebo vlnovku a prázdné řádky a komentáře s mřížkou se ignorují.
Znovu vygenerujte a ověřte výsledek
Pořadí se uplatní, když aktualizační skripty soubor znovu sestaví. Spusťte podporovanou aktualizační cestu místo úpravy generovaného výstupu a pak si přečtěte, co překladač skutečně dostal.
resolvconf -u
cat /etc/resolv.conf
Ověřte dva dotazy, ne jeden: soukromý název, který se má přeložit tunelem, a veřejný kontrolní název. Pokud soukromý název stále selhává, i když pořadí vypadá správně, je problém ve směrování jmenného prostoru, ne v prioritě záznamů, a žádné přeskládání to nespraví. Každou odpověď porovnejte se serverem, který ji vrátil, ne jen s úspěchem. Soukromý název zodpovězený špatným překladačem je pořád selhání a uživateli to připadá jako výpadek DNS.
Vyřaďte zastaralý záznam místo toho, abyste ho degradovali
Zastaralý záznam VPN, který se po odpojení znovu objevuje, je chyba životního cyklu v integraci klienta. Přesun na konec skryje příznak a v seznamu nechá mrtvý překladač.
Vyřaďte ho přes komponentu, která ho registruje, a poté ověřte, že adresář záznamů už ho neobsahuje.
Zapište název dodavatele, vzor, který jste změnili, a dva dotazy, které jste spustili. Dalšímu člověku jsou ty názvy užitečnější než příběh.