Ako čítať smerovanie VPN DNS pre každé pripojenie z resolvectl
resolvectl status zobrazuje servery, domény a predvolenú trasu pre každé pripojenie. Čítajte ich spolu, potom sa spýtajte na názov a poznamenajte, ktoré pripojenie odpovedalo.
Spustite resolvectl status a dostanete stenu blokov pre každé pripojenie, každý s vlastnými servermi a vlastným riadkom domén. Riadok, ktorý rozhoduje o smerovaní, je zoznam domén, nie adresa menného servera, pretože miestny stub odosiela každú požiadavku tomu pripojeniu, ktoré si nárokuje názov. Prečítajte si tieto nároky skôr, než prečítate odpoveď, potom sa spýtajte na názov a skontrolujte, ktoré pripojenie ho vytvorilo. Nesprávna odpoveď zo správneho pripojenia je iný problém než správna odpoveď z nesprávneho.
Čo vám hovorí každý blok pre pripojenie
Každý blok uvádza servery, ktoré resolver použije pre toto rozhranie, zoznam domén a či je pripojenie predvolenou trasou. Zoznam domén je sada nárokov a resolver uplatňuje zhodu najdlhšej prípony: požiadavku na host.corp.example si nárokuje pripojenie s corp.example skôr než to, ktoré má len predvolenú trasu. Dve pripojenia nárokujúce si rovnakú príponu nechávajú výsledok na priorite a poradí, preto si duplikáty zaslúžia pozornosť ako prvé. Riadok aktuálneho servera ukazuje, ktorý z uvedených serverov sa práve používa.
Adresa stubu ako 127.0.0.53 v /etc/resolv.conf hovorí len to, že stub je vpredu. Neuvádza nadradený zdroj, ktorý odpovedal, preto diagnostika založená len na resolv.conf uviazne.
Čítajte tri druhy záznamov domény správne
| Záznam | Čo si nárokuje | Bežná chyba |
|---|---|---|
| corp.example | doména smerovania a prípona hľadania: názvy pod ňou idú na toto pripojenie a reťazec sa pridáva k holým názvom | odstránené, pretože smerovanie aj tak vyzerá, že funguje |
| ~corp.example | len trasa: názvy pod ňou idú na toto pripojenie, ale prípona sa nepridáva | predpokladalo sa, že je potrebný na smerovanie |
| ~. | predvolená trasa: nárokuje požiadavky, ktoré nepokrýva žiadne iné pripojenie | ponechané aktívne na rozdelenom profile, takže verejné názvy idú tunelom |
Tilda mení správanie hľadania, nie smerovanie. Záznam bez tildy je zároveň doménou smerovania aj doménou hľadania, takže názvy pod ňou sa posielajú na to pripojenie a jednoznačkovým názvom sa pridáva prípona. Záznam s tildou smeruje rovnakú príponu, ale drží ju mimo zoznamu hľadania. Preto odstránenie tildy mení, ktoré holé názvy sa preložia, a preto chýbajúca tilda je problém hľadania, nie zlyhanie rozdeleného DNS.
Záznam predvolenej trasy si nárokuje všetko, čo nepokrýva žiadne iné pripojenie. Profil plného tunela ju zvyčajne chce a rozdelený profil zvyčajne nie, pretože verejné názvy potom cestujú k súkromnému resolveru a môžu tam zlyhať. Čítajte tabuľku proti zámeru profilu namiesto kopírovania príznakov medzi profilmi. Keď si dve pripojenia nárokujú rovnakú príponu, vyriešte otázku priority skôr, než upravíte čokoľvek iné.
Spýtajte sa na názov a pozrite, ktoré pripojenie odpovedalo
Podpríkaz query vypíše adresu, protokol a pripojenie alebo rozsah, ktoré vytvorili odpoveď. Otestujte jeden názov, ktorý by si mala nárokovať súkromná prípona, a jeden bežný verejný názov, potom porovnajte hlásené zdroje. Ak súkromný názov odpovedá z bezdrôtového pripojenia, nárok chýba alebo je tunel dole; ak verejný názov na rozdelenom profile odpovedá z tunela, predvolená trasa je príliš široká. Tieto dve chyby vyzerajú v prehliadači rovnako a v tomto výstupe opačne.
resolvectl status
resolvectl query host.corp.exampleSledujte aj hlásený protokol, pretože odpoveď z vyrovnávacej pamäte alebo zo súboru hosts môže prísť bez toho, aby bol oslovený akýkoľvek nadradený zdroj. Odpoveď z vyrovnávacej pamäte dokazuje, že sa názov niekedy preložil, nie že ho súčasná politika smeruje správne.
Držte smerovanie názvov oddelene od smerovania paketov
Rozhodnutie resolvera nevytvára cestu. Zvolený server stále potrebuje trasu k svojej adrese a vrátená adresa stále potrebuje trasu do súkromnej siete, takže správna politika DNS môže existovať vedľa pripojenia, ktoré sa nikdy neotvorí. Keď sa názov preloží a aplikácia zlyhá, preskúmajte adresu a trasu namiesto toho, aby ste znova menili DNS. Preklad názvov a dostupnosť sú dve otázky s dvoma rôznymi vlastníkmi.
Aplikácie môžu úplne obísť systémový resolver cez vlastné nastavenie zabezpečeného DNS alebo vstavaný resolver. Výsledok resolvectl opisuje systémovú cestu a prehliadač, ktorý ho ignoruje, bude nesúhlasiť s každým vaším testom. Skontrolujte to nastavenie, skôr než usúdite, že politika je rozbitá.
Zaznamenajte adresu, na ktorú sa názov preložil, vedľa pripojenia. Správny názov ukazujúci na nesprávnu adresu je problém záznamu, nie smerovania.
Skontrolujte znova po zmene pripojenia
Opätovné pripojenie alebo prepnutie bezdrôtovej siete znova zostaví stav pripojenia a správca siete môže preinštalovať svoje domény a servery nad všetko nastavené ručne. Potom sa spýtajte na tie isté dva názvy a porovnajte so zaznamenanou základnou líniou. Ak ručná úprava zmizla, oprava patrí do profilu pripojenia a nie do príkazu v shelli. Práve zaznamenanie pred a po to robí viditeľným.
Zdieľajte len názvy a kontext serverov, ktoré správa potrebuje, pretože vnútorné prípony prezrádzajú topológiu. Dokumentácia systemd-resolved o smerovaní domén pokrýva pravidlo najdlhšej zhody a správanie tildy a jedno prečítanie zabráni väčšine chýb v tabuľke vyššie: smerovanie požiadaviek v systemd-resolved.