Kiel legi la VPN-DNS-enkursigadon por ĉiu ligo el resolvectl
resolvectl status montras servilojn, domajnojn kaj la defaŭltan itineron por ĉiu ligo. Legu ilin kune, poste demandu la nomon kaj notu, kiu ligo respondis.
Rulu resolvectl status kaj vi ricevos muron da blokoj por ĉiu ligo, ĉiu kun propraj serviloj kaj propra domajna linio. La linio, kiu decidas la enkursigadon, estas la domajna listo, ne la adreso de la nomservilo, ĉar la loka stubo plusendas ĉiun demando al tiu ligo, kiu pretendas la nomon. Legu tiujn pretendojn antaŭ ol legi la respondon, poste demandu la nomon kaj kontrolu, kiu ligo produktis ĝin. Malĝusta respondo de la ĝusta ligo estas alia problemo ol ĝusta respondo de la malĝusta.
Kion diras al vi ĉiu bloko por ligo
Ĉiu bloko listigas la servilojn, kiujn la solvilo uzos por tiu interfaco, la domajnan liston kaj ĉu la ligo estas la defaŭlta itinero. La domajna listo estas aro da pretendoj, kaj la solvilo aplikas kongruon de la plej longa sufikso: demandon pri host.corp.example pretendas ligo portanta corp.example antaŭ unu portanta nur la defaŭltan itineron. Du ligoj pretendantaj la saman sufikson lasas la rezulton al prioritato kaj ordo, tial duoblaĵoj meritas atenton unue. La nuna servilla linio montras, kiu el la listigitaj serviloj estas uzata en tiu momento.
Stuba adreso kiel 127.0.0.53 en /etc/resolv.conf diras nur, ke la stubo estas antaŭe. Ĝi ne nomas la supran fluon, kiu respondis, tial diagnozo bazita nur sur resolv.conf blokiĝas.
Legu la tri specojn de domajnaj enskriboj ĝuste
| Enskribo | Kion ĝi pretendas | Kutima eraro |
|---|---|---|
| corp.example | enkursigada domajno kaj serĉa sufikso: nomoj sub ĝi iras al tiu ligo, kaj la ĉeno aldoniĝas al nudaj nomoj | forigita ĉar la enkursigado ŝajne funkcias ĉiuokaze |
| ~corp.example | nur itinero: nomoj sub ĝi iras al tiu ligo, sed la sufikso ne aldoniĝas | supozita kiel necesa por la enkursigado |
| ~. | defaŭlta itinero: pretendas demandojn, kiujn neniu alia ligo kovras | lasita aktiva sur dividita profilo, do publikaj nomoj sekvas la tunelon |
La tildo ŝanĝas serĉan konduton, ne enkursigadon. Enskribo sen tildo estas kaj enkursigada domajno kaj serĉa domajno, do nomoj sub ĝi estas sendataj al tiu ligo kaj al unuetikedaj nomoj aldoniĝas la sufikso. Tilda enskribo enkursigas la saman sufikson sed tenas ĝin ekster la serĉa listo. Tial forigo de tildo ŝanĝas, kiuj nudaj nomoj solviĝas, kaj tial mankanta tildo estas serĉa problemo kaj ne fiasko de dividita DNS.
La enskribo de la defaŭlta itinero pretendas ĉion, kion neniu alia ligo kovras. Profilo de plena tunelo kutime volas ĝin kaj dividita profilo kutime ne, ĉar publikaj nomoj tiam vojaĝas al la privata solvilo kaj povas fiaski tie. Legu la tabelon kontraŭ la intenco de la profilo anstataŭ kopii flagojn inter profiloj. Kiam du ligoj pretendas la saman sufikson, solvu la demandon pri prioritato antaŭ ol redakti ion alian.
Demandu nomon kaj vidu, kiu ligo respondis
La subkomando query presas la adreson, la protokolon kaj la ligon aŭ amplekson, kiuj produktis la respondon. Testu unu nomon, kiun la privata sufikso devus pretendi, kaj unu ordinaran publikan nomon, poste komparu la raportitajn fontojn. Se la privata nomo respondas el la sendrata ligo, la pretendo mankas aŭ la tunelo estas malsupre; se publika nomo sur dividita profilo respondas el la tunelo, la defaŭlta itinero estas tro larĝa. Tiuj du fiaskoj aspektas identaj en retumilo kaj malaj en ĉi tiu eligo.
resolvectl status
resolvectl query host.corp.exampleRigardu ankaŭ la raportitan protokolon, ĉar kaŝmemora respondo aŭ unu el la hosta dosiero povas alveni sen demandi iun supran fluon. Respondo el la kaŝmemoro pruvas, ke la nomo solviĝis iam, ne ke la nuna politiko enkursigas ĝin ĝuste.
Tenu nom-enkursigadon aparte de paketa enkursigado
Decido de solvilo ne kreas vojon. La elektita servilo ankoraŭ bezonas itineron al sia adreso, kaj la redonita adreso ankoraŭ bezonas itineron en la privatan reton, do ĝusta DNS-politiko povas kunekzisti kun konekto, kiu neniam malfermiĝas. Kiam nomo solviĝas kaj la aplikaĵo fiaskas, ekzamenu la adreson kaj la itineron anstataŭ denove ŝanĝi DNS. Nom-solvado kaj atingeblo estas du demandoj kun du malsamaj posedantoj.
Aplikaĵoj povas tute preterpasi la sisteman solvilon per propra agordo de sekura DNS aŭ per enkonstruita solvilo. La resolvectl-rezulto priskribas la sisteman vojon, kaj retumilo, kiu ignoras ĝin, malkonsentos kun ĉiu testo, kiun vi faras. Kontrolu tiun agordon antaŭ ol konkludi, ke la politiko estas rompita.
Notu la adreson, al kiu la nomo solviĝis, apud la ligo. Ĝusta nomo montranta al malĝusta adreso estas registra problemo, ne enkursigada.
Rekontrolu post kiam la ligo ŝanĝiĝis
Rekonekto aŭ sendrata ŝanĝo rekonstruas la ligan staton, kaj retadministrilo povas reinstali siajn domajnojn kaj servilojn super ĉio mane agordita. Poste demandu la samajn du nomojn kaj komparu kun la registrita bazo. Se mana redakto malaperis, la korekto apartenas al la konekta profilo kaj ne al ŝela komando. Registri antaŭe kaj poste estas tio, kio faras tion videbla.
Kunhavigu nur la nomojn kaj servilan kuntekston, kiujn la raporto bezonas, ĉar internaj sufiksoj malkaŝas topologion. La dokumentaro de systemd-resolved pri domajna enkursigado kovras la regulon de plej longa kongruo kaj la tildan konduton, kaj unufoja legado malhelpas la plejmulton de la tabelaj eraroj supre: demanda enkursigado en systemd-resolved.