Hvernig á að lesa VPN DNS-beiningu fyrir hverja tengingu úr resolvectl
resolvectl status sýnir netþjóna, lén og sjálfgefna leið fyrir hverja tengingu. Lestu þau saman, spurðu svo um nafnið og merktu við hvaða tenging svaraði.
Keyrðu resolvectl status og þú færð vegg af blokkum fyrir hverja tengingu, hver með sínum netþjónum og sinni lénalínu. Línan sem ræður beiningunni er lénslistinn, ekki heimilisfang nafnþjónsins, því staðbundna stubbið sendir hverja fyrirspurn til þeirrar tengingar sem gerir kröfu til nafnsins. Lestu þessar kröfur áður en þú lest svarið, spurðu svo um nafnið og athugaðu hvaða tenging framleiddi það. Rangt svar frá réttri tengingu er annað vandamál en rétt svar frá rangri tengingu.
Hvað segir hver blokk fyrir tengingu þér
Hver blokk telur upp netþjónana sem leysirinn mun nota fyrir það viðmót, lénslistann og hvort tengingin er sjálfgefna leiðin. Lénslistinn er mengi krafna, og leysirinn beitir samsvörun lengsta viðskeytis: fyrirspurn um host.corp.example er krafist af tengingu sem ber corp.example á undan þeirri sem ber aðeins sjálfgefnu leiðina. Tvær tengingar sem gera kröfu til sama viðskeytis láta niðurstöðuna eftir forgangi og röð, þess vegna eiga tvítekningar skilið athygli fyrst. Lína núverandi netþjóns sýnir hver af skráðum netþjónum er í notkun á því augnabliki.
Stub-heimilisfang eins og 127.0.0.53 í /etc/resolv.conf segir aðeins að stubbið sé framan við. Það nefnir ekki uppstreymið sem svaraði, þess vegna stöðvast greining sem byggir eingöngu á resolv.conf.
Lestu þrjár gerðir lénsfærslna rétt
| Færsla | Hvað hún krefst | Algeng mistök |
|---|---|---|
| corp.example | beiningarlén og leitarviðskeyti: nöfn undir því fara á þessa tengingu, og strengnum er bætt við ber nöfn | fjarlægt því beiningin virðist virka samt |
| ~corp.example | aðeins leið: nöfn undir því fara á þessa tengingu, en viðskeytinu er ekki bætt við | gert ráð fyrir að það þurfi fyrir beininguna |
| ~. | sjálfgefna leið: krefst fyrirspurna sem engin önnur tenging nær yfir | skilið eftir virkt á skiptri prófíl, svo opinber nöfn fylgja göngunni |
Tilda breytir leitarhegðun, ekki beiningunni. Færsla án tilda er bæði beiningarlén og leitarlén, svo nöfn undir henni eru send á þá tengingu og einmerkja nöfnum er viðskeytinu bætt við. Tilda-færsla beinir sama viðskeyti en heldur því utan leitarlistans. Þess vegna breytir það hvaða beru nöfn leysast þegar tilda er fjarlægð, og þess vegna er vantað tilda leitarvandamál en ekki bilun í skiptri DNS.
Færsla sjálfgefnu leiðarinnar krefst alls sem engin önnur tenging nær yfir. Prófíll fyrir fulla göng krefst hennar venjulega og skiptur prófíll venjulega ekki, því opinber nöfn ferðast þá til einkaleysisins og geta mistekist þar. Lestu töfluna gagnvart ætlun prófílsins í stað þess að afrita fána milli prófíla. Þegar tvær tengingar gera kröfu til sama viðskeytis, leystu forgangsspurninguna áður en þú breytir einhverju öðru.
Spurðu um nafn og sjáðu hvaða tenging svaraði
Undirskipunin query prentar heimilisfangið, samskiptaregluna og tenginguna eða umfangið sem framleiddi svarið. Prófaðu eitt nafn sem einkaviðskeytið ætti að krefjast og eitt venjulegt opinbert nafn, og berðu svo saman tilkynntu upprunana. Ef einkanafnið svarar frá þráðlausu tengingunni vantar kröfuna eða göngin eru niðri; ef opinbert nafn á skiptri prófíl svarar frá göngunum er sjálfgefna leiðin of breið. Þessar tvær bilanir líta eins út í vafra og andstætt út í þessari úttak.
resolvectl status
resolvectl query host.corp.exampleFylgstu líka með tilkynntri samskiptareglu, því svar úr skyndiminni eða úr hosts-skránni getur borist án þess að spurt sé um neitt uppstreymi. Svar úr skyndiminni sannar að nafnið leystist einhvern tíma, ekki að núverandi stefna beini því rétt.
Haltu nafnabeiningu aðskilinni frá pakkabeiningu
Ákvörðun leysisins skapar ekki slóð. Valdi netþjónninn þarf enn leið að heimilisfangi sínu, og skilað heimilisfang þarf enn leið inn í einkakerfið, svo rétt DNS-stefna getur lifað samhliða tengingu sem opnast aldrei. Þegar nafn leysist og forritið mistekst, skoðaðu heimilisfangið og leiðina í stað þess að breyta DNS aftur. Nafnaleysing og aðgengi eru tvær spurningar með tvo mismunandi eigendur.
Forrit geta sniðgengið kerfisleysinn algjörlega með eigin öruggri DNS-stillingu eða innbyggðum leysi. Niðurstaða resolvectl lýsir kerfisleiðinni, og vafri sem hunsar hana verður ósammála hverri prófun sem þú gerir. Athugaðu þá stillingu áður en þú ályktar að stefnan sé brotin.
Skráðu heimilisfangið sem nafnið leystist á við hlið tengingarinnar. Rétt nafn sem bendir á rangt heimilisfang er vandamál í færslu, ekki beiningu.
Athugaðu aftur eftir að tengingin breytist
Endurtenging eða þráðlaus skipting byggir stöðu tengingarinnar upp að nýju, og netstjóri getur sett lénin sín og netþjóna aftur ofan á allt sem stillt var handvirkt. Spurðu svo um sömu tvö nöfn og berðu saman við skráða grunnlínu. Ef handvirk breyting hvarf, á lagfæringin heima í tengiprófílnum en ekki í skeljarskipun. Það er skráningin fyrir og eftir sem gerir það sýnilegt.
Deildu aðeins þeim nöfnum og netþjónasamhengi sem skýrslan þarf, því innri viðskeyti opinbera topologíu. Skjölin systemd-resolved um lénsbeiningu ná yfir regluna um lengstu samsvörun og hegðun tildunnar, og ein lestur kemur í veg fyrir flestar villur í töflunni hér að ofan: fyrirspurnabeining í systemd-resolved.