Jak číst směrování VPN DNS pro každé připojení z výstupu resolvectl

Spusťte resolvectl status a dostanete zeď bloků pro každé připojení, každý s vlastními servery a vlastním řádkem domén. Řádek, který rozhoduje o směrování, je seznam domén, nikoli adresa jmenného serveru, protože místní stub předává každý dotaz tomu připojení, které si název nárokuje. Přečtěte si tyto nároky dřív, než přečtete odpověď, pak se zeptejte na název a zkontrolujte, které připojení ho vytvořilo. Špatná odpověď ze správného připojení je jiný problém než správná odpověď ze špatného.

Co vám říká každý blok pro připojení

Každý blok uvádí servery, které resolver pro toto rozhraní použije, seznam domén a zda je připojení výchozí trasou. Seznam domén je sada nároků a resolver uplatňuje shodu nejdelší přípony: dotaz na host.corp.example si nárokuje připojení nesoucí corp.example dřív než to, které nese jen výchozí trasu. Dvě připojení nárokující si stejnou příponu nechávají výsledek na prioritě a pořadí, proto si duplikáty zaslouží pozornost jako první. Řádek aktuálního serveru ukazuje, který z uvedených serverů se právě používá.

Adresa stuba jako 127.0.0.53 v /etc/resolv.conf říká jen, že stub je vpředu. Neuvádí nadřazený server, který odpověděl, proto diagnostika založená jen na resolv.conf uvízne.

Čtěte tři druhy záznamů domény správně

Tilda mění chování hledání, ne směrování. Záznam bez tildy je zároveň doménou směrování i doménou hledání, takže názvy pod ní se posílají na toto připojení a jednoznačkovým názvům se přidává přípona. Záznam s tildou směruje stejnou příponu, ale drží ji mimo seznam hledání. Proto odstranění tildy mění, které holé názvy se přeloží, a proto chybějící tilda je problém hledání, ne selhání rozděleného DNS.

Záznam výchozí trasy si nárokuje vše, co žádné jiné připojení nepokryje. Profil plného tunelu ji obvykle chce a rozdělený profil obvykle ne, protože veřejné názvy pak putují k privátnímu resolveru a mohou tam selhat. Čtěte tabulku proti záměru profilu, místo abyste kopírovali příznaky mezi profily. Když si dvě připojení nárokují stejnou příponu, vyřešte otázku priority dřív, než upravíte cokoli jiného.

Zeptejte se na název a podívejte se, které připojení odpovědělo

Podpříkaz query vypíše adresu, protokol a připojení nebo rozsah, které odpověď vytvořily. Otestujte jeden název, který by si měla nárokovat privátní přípona, a jeden běžný veřejný název, pak porovnejte hlášené zdroje. Pokud privátní název odpovídá z bezdrátového připojení, nárok chybí nebo je tunel dole; pokud veřejný název na rozděleném profilu odpovídá z tunelu, výchozí trasa je příliš široká. Tyto dvě chyby vypadají v prohlížeči stejně a v tomto výstupu opačně.

resolvectl status
resolvectl query host.corp.example

Sledujte i hlášený protokol, protože odpověď z mezipaměti nebo ze souboru hostitelů může přijít, aniž by byl dotázán jakýkoli nadřazený server. Odpověď z mezipaměti dokazuje, že se název někdy přeložil, ne že ho současná politika směruje správně.

Držte směrování názvů oddělené od směrování paketů

Rozhodnutí resolveru nevytváří cestu. Zvolený server stále potřebuje trasu ke své adrese a vrácená adresa stále potřebuje trasu do privátní sítě, takže správná politika DNS může existovat vedle připojení, které se nikdy neotevře. Když se název přeloží a aplikace selže, prohlédněte adresu a trasu, místo abyste znovu měnili DNS. Překlad názvů a dosažitelnost jsou dvě otázky se dvěma různými vlastníky.

Aplikace mohou systémový resolver úplně obejít přes vlastní nastavení zabezpečeného DNS nebo vestavěný resolver. Výsledek resolvectl popisuje systémovou cestu a prohlížeč, který ho ignoruje, bude nesouhlasit s každým vaším testem. Zkontrolujte to nastavení, než usoudíte, že politika je rozbitá.

Zaznamenejte adresu, na kterou se název přeložil, vedle připojení. Správný název ukazující na špatnou adresu je problém záznamu, ne směrování.

Zkontrolujte znovu po změně připojení

Opětovné připojení nebo přepnutí bezdrátové sítě znovu sestaví stav připojení a správce sítě může přeinstalovat své domény a servery přes vše nastavené ručně. Poté se zeptejte na stejné dva názvy a porovnejte se zaznamenanou základní linií. Pokud ruční úprava zmizela, oprava patří do profilu připojení a ne do příkazu v shellu. Právě zaznamenání před a po to činí viditelným.

Sdílejte jen názvy a kontext serverů, které zpráva potřebuje, protože vnitřní přípony prozrazují topologii. Dokumentace systemd-resolved ke směrování domén pokrývá pravidlo nejdelší shody a chování tildy a jedno přečtení zabrání většině chyb v tabulce výše: směrování dotazů systemd-resolved.