Razdeljeni DNS in VPN: pravila domen niso IP poti
Razdeljeni DNS izbere razreševalnik po imenu, odgovor pa še vedno potrebuje pot. Preizkusite pravilo domene in pot ločeno, na platformi, ki jo resnično uporabljate.
Vaš prenosnik razrešuje intranet.corp skozi tunel, medtem ko gitlab.com še vedno gre do razreševalnika ponudnika, in to je ureditev, ki deluje po načrtu. Ustvarili sta jo dve ločeni odločitvi: pravilo ujemanja imena je izbralo razreševalnik, pot pa je prinesla odgovor nazaj. Zlomite katero koli in brskalnik pokaže napako, ki je od zunaj videti enaka. Večina poročil o razdeljenem DNS opisuje drugo napako, hkrati pa navaja dokaze o prvi.
Dve polovici živita na različnih mestih in ju običajno urejajo različni ljudje. Ena je politika DNS, pritrjena na profil VPN, druga je pot, ki jo tunel namesti ali zadrži. Odpravljanje napak se ustavi, ko nihče ne ugotovi, katera polovica se je dejansko premaknila.
Dve odločitvi, skriti v eni zahtevi
Polovica imena je predmet politike, ne pot. V Windowsu je to politika razreševanja imen na profilu VPN; na platformah Apple nabor ujemajočih se domen na objektu nastavitev DNS; v Linuxu domena usmerjanja, vrstica razdeljenega razreševalnika ali vrstni red stikala imenske storitve. Polovica poti je običajno usmerjanje, ki ga namesti tunel ali roka, in nima pojma, kaj je ime gostitelja. Profil, ki dopušča pripono, odloči le, kdo odgovori; nikoli ne naredi odgovora dosegljivega.
Hiter test simptomov ju loči: zamenjajte ime z naslovom. Če naslov deluje, je pot v redu in pravilo napačno. Če tudi naslov ne uspe, je pravilo lahko pravilno in pot manjka.
Kako vsaka platforma izraža isto pravilo imen
Namen je enak, imena polj pa ne. Primer, kopiran z enega odjemalca na drugega, se razčleni čisto in se nikoli ne ujema. Tri oblike izgledajo takole:
| 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 |
Domena ujemanja ali usmerjanja je preizkus pripone, zato intranet.corp pokriva git.intranet.corp in ne pokriva corp.intranet, obrat tega pa je najpogostejša napaka v celotni nastavitvi. Windows nosi preslikavo kot politiko razreševanja imen, pritrjeno na profil, z lastnim vrstnim redom prednosti proti katerem koli seznamu pripon, ki ga je vmesnik že imel. Platforme Apple pritrdijo ujemajoče se domene na objekt nastavitev DNS omrežne razširitve in sistem jih uporabi za vsak omejeni razreševalnik. Nobena od teh oblik ni pot in nobena ne more narediti nedosegljivega naslova dosegljivega. Referenca politika razreševanja imen v Windowsu navaja imena polj in pravila prednosti za to platformo, in to niso tista, ki jih uporabljajo dokumenti Apple ali systemd.
Pravilen odgovor še vedno potrebuje pot
Odgovor razreševalnika je le naslov, aplikacija pa mora še vedno priti do njega. Zasnova razdeljenega tunela pogosto potisne 10.20.0.0/16 in zadrži privzeto pot, zato se notranje ime razreši in povezava nato obvisi. Nasprotni primer je enako pogost: pot obstaja, javni razreševalnik odgovori na zasebno ime z NXDOMAIN in napaka se zabeleži kot težava usmerjanja. Če najprej preizkusite pot, strmite v poti za ime, ki se ne bi nikoli razrešilo.
Obstajajo tudi tretja vrata, ki jih nobena polovica ne pokrije. ACL na prehodu, pravilo požarnega zidu ali politika na strani odjemalca lahko zavržejo povezavo potem, ko sta bili obe odločitvi pravilni. Ko se ime razreši, pot obstaja in povezava vseeno poteče, prenehajte preizkušati DNS.
Preizkušanje imen in poti v stalnem vrstnem redu
Izberite vrstni red in se ga držite, sicer boste lovili korak, ki je nazadnje spodletel. Razrešite dokumentirano polno notranje ime, potrdite, da je odgovor naslov, ki ga lahko nosi usmerjevalna tabela, nato ponovite z javnim imenom, da dokažete, da tunel ni ujel vsega. Na gostitelju systemd sta poizvedba in domena usmerjanja razreševalnika en ukaz narazen:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Odjemalec Windows postavi isti dve vprašanji z drugimi ukazi cmdlet. Drugi poroča vmesnik, ki bi ga sistem dejansko uporabil:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Če iskanje vrne naslov in preverjanje poti imenuje fizični vmesnik, je pravilo imen delovalo, pot pa ne. Če kratko ime spodleti, medtem ko se polno ime razreši, je napačen seznam pripon in ne razreševalnik.
Kje primerjava običajno gre narobe
Prva napaka je vprašati nepovezan javni razreševalnik o zasebnem imenu in zavrnitev brati kot dokaz o VPN. Druga je domnevati, da delujoče javno iskanje dokazuje pot razreševalnika tunela. Tretja je obravnavati razdeljeno tuneliranje in razdeljeni DNS kot eno oblikovalsko odločitev, čeprav je lahko uvedba pravilna v enem in pokvarjena v drugem. Vsaka napaka daje samozavestne sklepe iz preizkusa, ki nikoli ni vadil obtoženega dela.
Brskalnik z lastnim varnim DNS lahko prav tako obide sistemsko pravilo, zato to, da en brskalnik spodleti, medtem ko drugi uspe, ni protislovje. Primerjajte razreševalnik, ki je odgovoril, ne brskalnika, ki se je pritožil.
Ko sta obe polovici vidni, je preostalo vprašanje vprašanje politike in ne tehnično: kateri imenski prostori pripadajo organizaciji, kdo ima vsak odgovor in kateri od njih bi sploh morali zapustiti stroj. Zapišite to ob profilu, ker bo naslednja oseba, ki se bo dotaknila pravila, to potrebovala.