Odoslaný DNS server je v logu, tunel je hore a interné mená stále zlyhávajú. Na samotnom odoslaní nie je nič pokazené; nastavenie dorazilo a tam sa zastavilo. Odoslaná voľba DNS je správa klientovi, nie pokyn pre resolver operačného systému, a práve odovzdanie medzi nimi je miesto, kde sa väčšina týchto prípadov končí. Päť kontrol v poradí nájde odovzdanie, ktoré sa neuskutočnilo.

Kontrola prvá: ako sa pripojenie začína

Vlastník pripojenia určuje, kto môže použiť nastavenia resolvera. Priamy príkaz openvpn z shellu nevlastní nič okrem svojho procesu, zatiaľ čo jednotka systemd, NetworkManager alebo klientský program výrobcu má každý svoj spôsob publikovania DNS. Predtým než niektorý z nich predpokladáte, prečítajte si zoznam procesov a názov jednotky.

Proces z príkazového riadka nie je automaticky pripojením NetworkManageru a pripojenie NetworkManageru nie je automaticky tým, čo napísalo resolv.conf. Tieto dva predpoklady vysvetľujú väčšinu premárnených hodín pri tomto vyšetrovaní. Spýtajte sa, ktorý komponent by publikoval DNS pre rozhranie, ktoré skutočne vidíte.

Predtým než budete pokračovať, zapíšte si vlastníka. Každá ďalšia kontrola na ňom závisí.

Kontrola druhá: čo prepojenie resolvera skutočne obsahuje

Na hostiteľovi so systemd-resolved vypisuje resolvectl status každé prepojenie s jeho DNS servermi a doménami. Nájdite prepojenie tunela a prečítajte jeho položky a nepredpokladajte, že sa rozhranie volá tun0, pretože číslovanie nasleduje poradie vytvorenia. Ak na prepojení chýba odoslaná adresa, zlyhalo odovzdanie, nie dotaz.

Ak je adresa prítomná, ďalšou otázkou je, ktoré domény si toto prepojenie nárokuje. Prepojenie bez zoznamu domén odpovedá iba na mená, na ktoré sa pýtame priamo, a to je zriedka to, čo nasadenie split-DNS chce. Samotná adresa je nutná, ale nie postačujúca.

Pred akýmkoľvek záverom porovnajte názov prepojenia vo výstupe resolvera s názvom rozhrania v logu VPN. Nesúlad tam zvyčajne znamená, že riadok logu prišiel z iného procesu.

Kontrola tretia: či menný priestor volí toto prepojenie

Resolver môže mať správny server a napriek tomu sa ho nikto nepýta. Doména na prepojenie rozhoduje, ktoré dopyty idú na ktoré prepojenie, a bez smerovacej domény súkromný menný priestor padá späť na to, čo hovorí predvolené prepojenie. Preto môže resolvectl query pre interné meno uspieť, zatiaľ čo aplikácia stále zlyháva. Aplikácia môže používať úplne inú cestu resolvera.

Skontrolujte pridelenie domény, nie len adresu servera. Doména zapísaná ako ~corp.example je smerovacia doména a vlnovka mení spôsob porovnávania mena.

Ak má aplikácia vlastný resolver, testujte rovnakým mechanizmom, ktorý používa ona, nie systémovým nástrojom. Nástroj na dopyty, ktorý obchádza systémový resolver, uspeje bez ohľadu na stav prepojenia.

Kontrola štvrtá: jeden vlastník, nie dvaja

Ak NetworkManager už spravuje VPN aj stav resolvera, pridanie nesúvisiaceho hook skriptu vytvára súperiacich zapisovateľov. Hook, ktorý balík poskytuje pre systemd-resolved, je podporovaná integrácia a očakáva určitý životný cyklus: script-security 2, cestu up, up-restart, cestu down a down-pre. Tieto voľby spôsobujú, že registrácia a odstránenie prebehnú v správnych okamihoch, nie len pri prvom pripojení.

Použite nainštalovanú cestu z balíka, nie ilustratívnu skopírovanú z návodu. Na oprávneniach tiež záleží, pretože hook beží po znížení oprávnení.

Úprava resolverového skriptu distribúcie na zmenu jeho výstupného cieľa zaznamenáva obchádzku pre jedného hostiteľa. Nie je to všeobecná oprava.

Kontrola piata: rovnaký výsledok po opätovnom pripojení

Pripojte sa znova a prečítajte prepojenie znova. Registrácia, ktorá sa objaví raz a zmizne pri ďalšom prechode, je porucha, pre ktorú celý tento kontrolný zoznam existuje. Testujte po uspatí, po vynútenom opätovnom pripojení a po reštarte služby resolvera. Každý prechod preveruje iný predpoklad o poradí.

Až keď pri opätovnom pripojení prejde všetkých päť kontrol, môžete povedať, že odoslané nastavenia sa používajú. Čokoľvek skoršie je snímka šťastného okamihu.

Súvisiace články