Cum se citește rutarea DNS a VPN-ului pe legătură din resolvectl
resolvectl status arată servere, domenii și ruta implicită pe fiecare legătură. Citește-le împreună, apoi interoghează numele și notează care legătură a răspuns.
Rulați resolvectl status și obțineți un zid de blocuri pe legătură, fiecare cu serverele sale și cu linia sa de domenii. Linia care decide rutarea este lista de domenii, nu adresa serverului de nume, pentru că stub-ul local trimite fiecare interogare către legătura care revendică numele. Citiți aceste revendicări înainte de a citi răspunsul, apoi interogați numele și verificați care legătură l-a produs. Un răspuns greșit de la legătura corectă este o problemă diferită de un răspuns corect de la legătura greșită.
Ce vă spune fiecare bloc pe legătură
Fiecare bloc listează serverele pe care resolverul le va folosi pentru acea interfață, lista de domenii și dacă legătura este ruta implicită. Lista de domenii este un set de revendicări, iar resolverul aplică potrivirea celui mai lung sufix: o interogare pentru host.corp.example este revendicată de o legătură care poartă corp.example înaintea uneia care poartă doar ruta implicită. Două legături care revendică același sufix lasă rezultatul la prioritate și ordine, de aceea duplicatele merită atenție primele. Linia serverului curent arată care dintre serverele listate este folosit în acel moment.
O adresă stub precum 127.0.0.53 în /etc/resolv.conf spune doar că stub-ul este în față. Nu numește sursa care a răspuns, de aceea un diagnostic bazat doar pe resolv.conf se blochează.
Citiți corect cele trei tipuri de intrări de domeniu
| Intrare | Ce revendică | Greșeală obișnuită |
|---|---|---|
| corp.example | domeniu de rutare și sufix de căutare: numele de sub el merg la această legătură, iar șirul este adăugat la numele simple | eliminat pentru că rutarea pare să funcționeze oricum |
| ~corp.example | doar rută: numele de sub el merg la această legătură, dar sufixul nu este adăugat | s-a presupus că este necesar pentru rutare |
| ~. | ruta implicită: revendică interogările pe care nicio altă legătură nu le acoperă | lăsat activ pe un profil divizat, astfel încât numele publice urmează tunelul |
Tilda schimbă comportamentul căutării, nu rutarea. O intrare fără tildă este atât domeniu de rutare, cât și domeniu de căutare, deci numele de sub ea sunt trimise la acea legătură, iar numele cu o singură etichetă primesc sufixul. O intrare cu tildă rutează același sufix, dar îl ține în afara listei de căutare. De aceea eliminarea tildei schimbă care nume simple se rezolvă și de aceea o tildă lipsă este o problemă de căutare, nu o defecțiune a DNS-ului divizat.
Intrarea rutei implicite revendică tot ce nicio altă legătură nu acoperă. Un profil de tunel complet o vrea de obicei, iar un profil divizat de obicei nu, pentru că numele publice călătoresc atunci la resolverul privat și pot eșua acolo. Citiți tabelul față de intenția profilului în loc să copiați steaguri între profiluri. Când două legături revendică același sufix, rezolvați problema priorității înainte de a edita orice altceva.
Interogați un nume și vedeți care legătură a răspuns
Subcomanda query tipărește adresa, protocolul și legătura sau domeniul de aplicare care au produs răspunsul. Testați un nume care ar trebui revendicat de sufixul privat și un nume public obișnuit, apoi comparați sursele raportate. Dacă numele privat răspunde de pe legătura fără fir, revendicarea lipsește sau tunelul este căzut; dacă un nume public pe un profil divizat răspunde din tunel, ruta implicită este prea largă. Aceste două eșecuri arată identic într-un browser și opus în această ieșire.
resolvectl status
resolvectl query host.corp.exampleUrmăriți și protocolul raportat, pentru că un răspuns din cache sau din fișierul hosts poate sosi fără ca vreo sursă să fie întrebată. Un răspuns din cache dovedește că numele s-a rezolvat cândva, nu că politica actuală îl rutează corect.
Țineți rutarea numelor separată de rutarea pachetelor
O decizie a resolverului nu creează o cale. Serverul ales are în continuare nevoie de o rută către adresa sa, iar adresa returnată are în continuare nevoie de o rută în rețeaua privată, deci o politică DNS corectă poate coexista cu o conexiune care nu se deschide niciodată. Când un nume se rezolvă și aplicația eșuează, inspectați adresa și ruta în loc să schimbați din nou DNS-ul. Rezolvarea numelor și accesibilitatea sunt două întrebări cu doi proprietari diferiți.
Aplicațiile pot ocoli complet resolverul sistemului prin propria setare de DNS securizat sau printr-un resolver inclus. Rezultatul resolvectl descrie calea sistemului, iar un browser care îl ignoră va fi în dezacord cu fiecare test pe care îl faceți. Verificați acea setare înainte de a concluziona că politica este stricată.
Notați adresa la care s-a rezolvat numele lângă legătură. Un nume corect care indică adresa greșită este o problemă de înregistrare, nu de rutare.
Verificați din nou după ce legătura se schimbă
O reconectare sau o schimbare de rețea fără fir reconstruiește starea legăturii, iar un manager de rețea poate reinstala domeniile și serverele sale peste tot ce a fost setat manual. Interogați apoi aceleași două nume și comparați cu linia de bază înregistrată. Dacă o modificare manuală a dispărut, corectarea aparține profilului de conexiune și nu unei comenzi shell. Înregistrarea înainte și după este ce face asta vizibil.
Partajați doar numele și contextul serverelor de care are nevoie raportul, pentru că sufixele interne dezvăluie topologia. Documentația systemd-resolved despre rutarea domeniilor acoperă regula potrivirii celei mai lungi și comportamentul tildei, iar o singură lectură previne majoritatea greșelilor din tabelul de mai sus: rutarea interogărilor în systemd-resolved.