Si të lexohet rrugëtimi DNS i VPN-së për çdo lidhje nga resolvectl
resolvectl status shfaq serverat, domenet dhe rrugën e paracaktuar për çdo lidhje. Lexojini së bashku, pastaj pyesni për emrin dhe shënoni cila lidhje u përgjigj.
Ekzekutoni resolvectl status dhe merrni një mur blloqesh për çdo lidhje, secili me serverat e vet dhe me rreshtin e vet të domeneve. Rreshti që vendos rrugëtimin është lista e domeneve, jo adresa e serverit të emrave, sepse stub-i lokal përcjell çdo kërkesë te lidhja që pretendon emrin. Lexojini ato pretendime përpara se të lexoni përgjigjen, pastaj pyesni për emrin dhe kontrolloni cila lidhje e prodhoi. Një përgjigje e gabuar nga lidhja e saktë është problem tjetër nga një përgjigje e saktë nga lidhja e gabuar.
Çfarë ju thotë çdo bllok për lidhje
Çdo bllok liston serverat që zgjidhësi do të përdorë për atë ndërfaqe, listën e domeneve dhe nëse lidhja është rruga e paracaktuar. Lista e domeneve është një grup pretendimesh, dhe zgjidhësi zbaton përputhjen e prapashtesës më të gjatë: një kërkesë për host.corp.example pretendohet nga një lidhje që mban corp.example përpara një që mban vetëm rrugën e paracaktuar. Dy lidhje që pretendojnë të njëjtën prapashtesë ia lënë rezultatin përparësisë dhe renditjes, prandaj dublikatat meritojnë vëmendje të parat. Rreshti i serverit aktual tregon cili prej serverëve të listuar është në përdorim në atë moment.
Një adresë stub si 127.0.0.53 në /etc/resolv.conf thotë vetëm se stub-i është përpara. Nuk e emërton burimin që u përgjigj, prandaj një diagnozë e bazuar vetëm në resolv.conf ngec.
Lexoni saktë tre llojet e zërave të domenit
| Zëri | Çfarë pretendon | Gabim i zakonshëm |
|---|---|---|
| corp.example | domen rrugëtimi dhe prapashtesë kërkimi: emrat poshtë tij shkojnë te kjo lidhje, dhe vargu i shtohet emrave të zhveshur | u hoq sepse rrugëtimi duket se funksionon gjithsesi |
| ~corp.example | vetëm rrugë: emrat poshtë tij shkojnë te kjo lidhje, por prapashtesa nuk shtohet | u supozua se është i nevojshëm për rrugëtimin |
| ~. | rruga e paracaktuar: pretendon kërkesat që asnjë lidhje tjetër nuk i mbulon | u la aktiv në një profil të ndarë, kështu që emrat publikë ndjekin tunelin |
Tilda ndryshon sjelljen e kërkimit, jo rrugëtimin. Një zë pa tildë është njëkohësisht domen rrugëtimi dhe domen kërkimi, prandaj emrat poshtë tij dërgohen te ajo lidhje dhe emrave me një etiketë u shtohet prapashtesa. Një zë me tildë rrugëton të njëjtën prapashtesë, por e mban jashtë listës së kërkimit. Prandaj heqja e tildës ndryshon cilët emra të zhveshur zgjidhen, dhe prandaj mungesa e tildës është problem kërkimi dhe jo dështim i DNS-së së ndarë.
Zëri i rrugës së paracaktuar pretendon gjithçka që asnjë lidhje tjetër nuk e mbulon. Një profil tuneli të plotë zakonisht e do atë dhe një profil i ndarë zakonisht jo, sepse emrat publikë atëherë shkojnë te zgjidhësi privat dhe mund të dështojnë atje. Lexojeni tabelën kundrejt qëllimit të profilit në vend që të kopjoni flamuj mes profileve. Kur dy lidhje pretendojnë të njëjtën prapashtesë, zgjidhni çështjen e përparësisë përpara se të redaktoni çdo gjë tjetër.
Pyesni për një emër dhe shihni cila lidhje u përgjigj
Nënkomanda query printon adresën, protokollin dhe lidhjen ose fushën që prodhuan përgjigjen. Provoni një emër që duhet të pretendohet nga prapashtesa private dhe një emër publik të zakonshëm, pastaj krahasoni burimet e raportuara. Nëse emri privat përgjigjet nga lidhja me valë, pretendimi mungon ose tuneli është poshtë; nëse një emër publik në një profil të ndarë përgjigjet nga tuneli, rruga e paracaktuar është shumë e gjerë. Këto dy dështime duken njësoj në një shfletues dhe të kundërta në këtë dalje.
resolvectl status
resolvectl query host.corp.exampleVëreni edhe protokollin e raportuar, sepse një përgjigje nga kujtesa ose nga skedari hosts mund të arrijë pa u pyetur asnjë burim më lart. Një përgjigje nga kujtesa provon që emri u zgjidh në ndonjë moment, jo që politika aktuale e rrugëton saktë.
Mbani rrugëtimin e emrave të ndarë nga rrugëtimi i paketave
Një vendim i zgjidhësit nuk krijon një rrugë. Serveri i zgjedhur ka ende nevojë për një rrugë drejt adresës së vet, dhe adresa e kthyer ka ende nevojë për një rrugë në rrjetin privat, prandaj një politikë e saktë DNS mund të bashkëjetojë me një lidhje që nuk hapet kurrë. Kur një emër zgjidhet dhe aplikacioni dështon, shqyrtoni adresën dhe rrugën në vend që të ndryshoni përsëri DNS. Zgjidhja e emrave dhe arritshmëria janë dy pyetje me dy pronarë të ndryshëm.
Aplikacionet mund të anashkalojnë plotësisht zgjidhësin e sistemit përmes konfigurimit të tyre të DNS-së të sigurt ose një zgjidhësi të integruar. Rezultati i resolvectl përshkruan rrugën e sistemit, dhe një shfletues që e injoron do të jetë në kundërshtim me çdo test që bëni. Kontrolloni atë konfigurim përpara se të konkludoni që politika është prishur.
Shënoni adresën në të cilën u zgjidh emri pranë lidhjes. Një emër i saktë që tregon adresën e gabuar është problem regjistri, jo rrugëtimi.
Kontrolloni përsëri pasi lidhja të ndryshojë
Një rilidhje ose një ndërrim me valë rindërton gjendjen e lidhjes, dhe një menaxher rrjeti mund të riinstalojë domenet dhe serverat e tij mbi gjithçka që është vendosur me dorë. Pastaj pyesni për të njëjtët dy emra dhe krahasoni me vijën bazë të regjistruar. Nëse një ndryshim manual është zhdukur, korrigjimi i takon profilit të lidhjes dhe jo një komande shell. Është regjistrimi para dhe pas ai që e bën të dukshme.
Ndani vetëm emrat dhe kontekstin e serverëve që raporti ka nevojë, sepse prapashtesat e brendshme zbulojnë topologjinë. Dokumentacioni i systemd-resolved për rrugëtimin e domeneve mbulon rregullin e përputhjes më të gjatë dhe sjelljen e tildës, dhe një lexim i vetëm parandalon shumicën e gabimeve të tabelës më sipër: rrugëtimi i kërkesave në systemd-resolved.