Jagatud DNS ja VPN: domeenireeglid ei ole IP-marsruudid
Jagatud DNS valib lahendaja nime järgi ja vastus vajab endiselt marsruuti. Testige domeenireeglit ja teed eraldi, platvormil, mida te tegelikult kasutate.
Teie sülearvuti lahendab intranet.corp tunneli kaudu, samal ajal kui gitlab.com läheb edasi teenusepakkuja lahendajasse, ja see ongi kavandatud viisil töötav lahendus. Selle tekitasid kaks eraldi otsust: nimevaste reegel valis lahendaja ja marsruut tõi vastuse tagasi. Katke kumb tahes ja brauser näitab tõrget, mis väljastpoolt vaadates näeb ühesugune välja. Enamik jagatud DNS-i aruandeid kirjeldab teist tõrget, tsiteerides samal ajal tõendeid esimese kohta.
Kaks poolt elavad eri kohtades ja neid muudavad tavaliselt eri inimesed. Üks on VPN-profiili külge kinnitatud DNS-poliitika, teine on marsruut, mille tunnel paigaldab või kinni hoiab. Silumine jääb seisma, kui keegi ei tee kindlaks, milline pool tegelikult liikus.
Kaks otsust ühes päringus peidus
Nimepool on poliitikaobjekt, mitte marsruut. Windowsis on see VPN-profiili nime lahendamise poliitika; Apple'i platvormidel vaste-domeenide hulk DNS-i seadete objektil; Linuxis marsruutimisdomeen, jagatud lahendaja rida või nimesideteenuse lüliti järjekord. Teepool on tavaline marsruutimine, mille paigaldab tunnel või käsitsi, ja sellel pole aimugi, mis on hostinimi. Profiil, mis lubab järelliidet, otsustab ainult, kes vastab; see ei tee vastust kunagi kättesaadavaks.
Kiire sümptomitest eraldab need: asendage nimi aadressiga. Kui aadress töötab, on tee korras ja reegel vale. Kui ka aadress ebaõnnestub, võib reegel olla õige ja tee puudu.
Kuidas iga platvorm sama nimireeglit väljendab
Kavatsus on identne ja väljade nimed ei ole. Ühest kliendist teise kopeeritud näide parsitakse puhtalt ja ei sobi kunagi. Kolm vormi näevad välja nii:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Vaste- või marsruutimisdomeen on järelliite test, seega intranet.corp katab git.intranet.corp ja ei kata corp.intranet, ning selle ümberpööramine on kogu seadistuse kõige levinum viga. Windows kannab vastendust profiili külge kinnitatud nime lahendamise poliitikana, millel on oma prioriteedijärjekord liidese juba olemasoleva järelliiteloendi suhtes. Apple'i platvormid kinnitavad vaste-domeenid võrgu laienduse DNS-i seadete objekti külge ja süsteem rakendab neid iga piiritletud lahendaja kohta. Ükski neist vormidest ei ole marsruut ja ükski ei suuda muuta kättesaamatut aadressi kättesaadavaks. Viide Windowsi nime lahendamise poliitika loetleb selle platvormi väljade nimed ja prioriteedireeglid ning need ei ole need, mida kasutavad Apple'i või systemdi dokumentatsioon.
Õige vastus vajab endiselt teed
Lahendaja vastus on ainult aadress ja rakendus peab ikkagi selleni jõudma. Jagatud tunneli lahendus lükkab tavaliselt 10.20.0.0/16 ja hoiab vaikimisi marsruudi kinni, nii et sisemine nimi lahendatakse ja ühendus jääb seejärel rippuma. Vastupidine juhtum on sama tavaline: marsruut on olemas, avalik lahendaja vastab privaatsele nimele NXDOMAIN-iga ja tõrge registreeritakse marsruutimisprobleemina. Tee testimine kõigepealt jätab teid vaatama marsruute nime jaoks, mida ei olnudki kunagi plaanis lahendada.
On ka kolmas värav, mida kumbki pool ei kata. ACL lüüsil, tulemüürireegel või kliendipoolne poliitika võivad ühenduse maha visata pärast seda, kui mõlemad otsused olid õiged. Kui nimi lahendatakse, marsruut on olemas ja ühendus aegub ikkagi, lõpetage DNS-i testimine.
Nimede ja teede testimine kindlas järjekorras
Valige järjekord ja hoidke sellest kinni, muidu jälitate sammu, mis ebaõnnestus kõige hiljem. Lahendage dokumenteeritud täielik sisemine nimi, kinnitage, et vastus on aadress, mida marsruutimistabel suudab kanda, seejärel korrake avaliku nimega, et tõestada, et tunnel ei haaranud kõike. systemd-hostis on päring ja lahendaja marsruutimisdomeen ühe käsu kaugusel:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windowsi klient küsib samu kahte küsimust teiste cmdlet-idega. Teine teatab liidese, mida süsteem tegelikult kasutaks:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Kui otsing tagastab aadressi ja tee kontroll nimetab füüsilise liidese, siis nimireegel töötas ja marsruut mitte. Kui lühike nimi ebaõnnestub, samal ajal kui täielik nimi lahendatakse, on viga järelliiteloendis, mitte lahendajas.
Kus võrdlus tavaliselt untsu läheb
Esimene viga on küsida kõrvaliselt avalikult lahendajalt privaatse nime kohta ja lugeda keeldumist tõendiks VPN-i kohta. Teine on eeldada, et töötav avalik otsing tõestab tunneli lahendaja teed. Kolmas on käsitleda jagatud tunnelit ja jagatud DNS-i ühe kavandamisotsusena, kuigi juurutus võib olla ühes õige ja teises katki. Iga viga annab enesekindlad järeldused testist, mis ei harjutanud kunagi süüdistatavat osa.
Oma turvalise DNS-iga brauser võib samuti süsteemireeglist mööda minna, seetõttu ei ole see vastuolu, et üks brauser ebaõnnestub, samal ajal kui teine õnnestub. Võrrelge lahendajat, mis vastas, mitte brauserit, mis kaebas.
Kui mõlemad pooled on nähtavad, on järelejäänud küsimus poliitika, mitte tehniline: millised nimeruumid kuuluvad organisatsioonile, kes omab iga vastust ja millised neist peaksid masinast üldse lahkuma. Kirjutage see profiili kõrvale, sest järgmine inimene, kes reeglit puudutab, vajab seda.