Paano basahin ang VPN DNS routing bawat link mula sa resolvectl

Patakbuhin ang resolvectl status at makakakuha ka ng pader ng mga bloke bawat link, bawat isa may sariling mga server at sariling linya ng domain. Ang linyang nagpapasya sa routing ay ang listahan ng domain, hindi ang address ng name server, dahil ipinapasa ng lokal na stub ang bawat query sa link na nag-aangkin ng pangalan. Basahin ang mga pag-angkin bago basahin ang sagot, pagkatapos itanong ang pangalan at tingnan kung aling link ang gumawa nito. Ang maling sagot mula sa tamang link ay ibang problema kaysa tamang sagot mula sa maling link.

Ano ang sinasabi ng bawat bloke bawat link

Inililista ng bawat bloke ang mga server na gagamitin ng resolver para sa interface na iyon, ang listahan ng domain at kung ang link ay ang default na ruta. Ang listahan ng domain ay isang set ng mga pag-angkin, at ginagamit ng resolver ang pagtutugma ng pinakamahabang suffix: ang query para sa host.corp.example ay inaangkin ng link na may corp.example bago ang may default na ruta lamang. Dalawang link na nag-aangkin ng parehong suffix ay iniiwan ang resulta sa priyoridad at pagkakasunod-sunod, kaya ang mga duplicate ay dapat bigyan ng pansin muna. Ipinapakita ng linya ng kasalukuyang server kung alin sa mga nakalistang server ang ginagamit sa sandaling iyon.

Ang stub address tulad ng 127.0.0.53 sa /etc/resolv.conf ay nagsasabi lamang na ang stub ay nasa harap. Hindi nito pinapangalanan ang upstream na sumagot, kaya ang diagnosis na nakabatay lamang sa resolv.conf ay tumitigil.

Basahin nang tama ang tatlong uri ng domain entry

Binabago ng tilde ang pag-uugali ng paghahanap, hindi ang routing. Ang entry na walang tilde ay routing domain at search domain, kaya ang mga pangalan sa ilalim nito ay ipinapadala sa link na iyon at ang mga pangalang may isang label ay nadadagdagan ng suffix. Ang entry na may tilde ay nagruruta ng parehong suffix ngunit pinapanatili itong labas ng listahan ng paghahanap. Kaya binabago ng pagtanggal ng tilde kung aling mga hubad na pangalan ang nareresolba, at kaya ang nawawalang tilde ay problema sa paghahanap, hindi pagkabigo ng split DNS.

Ang entry ng default na ruta ay nag-aangkin ng lahat ng walang ibang link na sumasaklaw. Karaniwang gusto ito ng full-tunnel na profile at karaniwang hindi ng split na profile, dahil ang mga pampublikong pangalan ay naglalakbay noon sa pribadong resolver at maaaring mabigo doon. Basahin ang talahanayan laban sa layunin ng profile sa halip na kopyahin ang mga flag sa pagitan ng mga profile. Kapag dalawang link ang nag-aangkin ng parehong suffix, ayusin ang isyu ng priyoridad bago i-edit ang anumang iba pa.

Itanong ang isang pangalan at tingnan kung aling link ang sumagot

Ang subcommand na query ay nagpi-print ng address, protocol at ang link o saklaw na gumawa ng sagot. Subukan ang isang pangalang dapat angkinin ng pribadong suffix at isang ordinaryong pampublikong pangalan, pagkatapos ihambing ang mga iniulat na pinagmulan. Kung ang pribadong pangalan ay sumasagot mula sa wireless na link, kulang ang pag-angkin o down ang tunnel; kung ang pampublikong pangalan sa split na profile ay sumasagot mula sa tunnel, masyadong malawak ang default na ruta. Ang dalawang pagkabigong iyon ay magkapareho sa browser at magkasalungat sa output na ito.

resolvectl status
resolvectl query host.corp.example

Pansinin din ang iniulat na protocol, dahil ang sagot mula sa cache o mula sa hosts file ay maaaring dumating nang walang pagtatanong sa anumang upstream. Ang sagot mula sa cache ay nagpapatunay na naresolba ang pangalan minsan, hindi na tama ang pagruruta ng kasalukuyang patakaran.

Ihiwalay ang routing ng pangalan sa routing ng packet

Ang desisyon ng resolver ay hindi gumagawa ng landas. Ang napiling server ay kailangan pa rin ng ruta patungo sa address nito, at ang ibinalik na address ay kailangan pa rin ng ruta papasok sa pribadong network, kaya ang tamang patakaran ng DNS ay maaaring mabuhay kasama ng koneksyong hindi kailanman bumubukas. Kapag naresolba ang pangalan at nabigo ang application, siyasatin ang address at ang ruta sa halip na palitan muli ang DNS. Ang resolusyon ng pangalan at abot-kamay ay dalawang tanong na may dalawang magkaibang may-ari.

Maaaring laktawan ng mga application ang system resolver nang buo sa pamamagitan ng sarili nilang secure DNS setting o bundled na resolver. Inilalarawan ng resulta ng resolvectl ang landas ng system, at ang browser na hindi ito pansinin ay hindi sasang-ayon sa bawat pagsubok na gagawin mo. Suriin ang setting na iyon bago magpasya na sira ang patakaran.

Itala ang address kung saan naresolba ang pangalan sa tabi ng link. Ang tamang pangalan na tumuturo sa maling address ay problema sa record, hindi sa routing.

Suriin muli pagkatapos magbago ang link

Ang muling pagkonekta o paglipat ng wireless ay muling bumubuo ng estado ng link, at ang network manager ay maaaring muling mag-install ng mga domain at server nito sa ibabaw ng anumang manu-manong itinakda. Pagkatapos ay itanong ang parehong dalawang pangalan at ihambing sa naitalang baseline. Kung nawala ang manu-manong pag-edit, ang pagwawasto ay nasa profile ng koneksyon at hindi sa command ng shell. Ang pagtatala bago at pagkatapos ang siyang nagpapakita nito.

Ibahagi lamang ang mga pangalan at konteksto ng server na kailangan ng ulat, dahil ibinubunyag ng mga panloob na suffix ang topolohiya. Sinasaklaw ng dokumentasyon ng systemd-resolved tungkol sa domain routing ang tuntunin ng pinakamahabang pagtutugma at ang pag-uugali ng tilde, at ang isang pagbabasa ay pumipigil sa karamihan ng mga pagkakamali sa talahanayan sa itaas: routing ng query sa systemd-resolved.