Osztott DNS és VPN: a doménszabályok nem IP-útvonalak

A laptopja az intranet.corp nevet az alagúton keresztül oldja fel, miközben a gitlab.com továbbra is a szolgáltató feloldójához megy, és ez az a felállás, amely a tervezés szerint működik. Két külön döntés hozta létre: egy névegyeztetési szabály választotta ki a feloldót, és egy útvonal hozta vissza a választ. Bontsa meg bármelyiket, és a böngésző olyan hibát mutat, amely kívülről ugyanolyannak látszik. Az osztott DNS-ről szóló jelentések többsége a második hibát írja le, miközben az elsőről szóló bizonyítékokat idézi.

A két fél különböző helyeken él, és általában különböző emberek szerkesztik őket. Az egyik a VPN-profilhoz csatolt DNS-szabályzat, a másik egy útvonal, amelyet az alagút telepít vagy visszatart. A hibakeresés elakad, amikor senki nem állapítja meg, melyik fél mozdult el valójában.

Két döntés egyetlen kérésben elrejtve

A név fele szabályzatobjektum, nem útvonal. Windowson névfeloldási szabályzat a VPN-profilban; Apple platformokon egyeztető tartományok halmaza egy DNS-beállítási objektumon; Linuxon útválasztási tartomány, osztott feloldósor vagy a névszolgáltatás-kapcsoló sorrendje. Az útvonal fele közönséges útválasztás, amelyet az alagút vagy kézzel telepít, és fogalma sincs arról, mi a gépnév. Az a profil, amely megenged egy utótagot, csak arról dönt, ki válaszol; soha nem teszi elérhetővé a választ.

Egy gyors tünetteszt szétválasztja őket: helyettesítse a nevet egy címmel. Ha a cím működik, az útvonal rendben van, és a szabály hibás. Ha a cím is meghiúsul, a szabály helyes lehet, és az útvonal hiányozhat.

Hogyan fejezi ki minden platform ugyanazt a névszabályt

A szándék azonos, a mezőnevek nem. Az egyik klienstől a másikba másolt példa tisztán elemezhető, és soha nem egyezik. A három forma így néz ki:

Az egyeztető vagy útválasztási tartomány utótagteszt, tehát az intranet.corp lefedi a git.intranet.corp nevet, és nem fedi le a corp.intranet nevet, és ennek megfordítása az egész beállítás leggyakoribb hibája. A Windows a leképezést a profilhoz csatolt névfeloldási szabályzatként hordozza, saját elsőbbségi sorrenddel a felület meglévő utótaglistájához képest. Az Apple platformok az egyeztető tartományokat a hálózati kiterjesztés DNS-beállítási objektumához csatolják, és a rendszer hatókörölt feloldónként alkalmazza őket. E formák egyike sem útvonal, és egyik sem tud elérhetetlen címet elérhetővé tenni. A Windows névfeloldási szabályzat hivatkozás felsorolja az adott platform mezőneveit és elsőbbségi szabályait, és azok nem azok, amelyeket az Apple vagy a systemd dokumentumai használnak.

A helyes válasznak még mindig kell útvonal

A feloldó válasza csak egy cím, és az alkalmazásnak mégis el kell érnie. Az osztott alagút kialakítása gyakran áttolja a 10.20.0.0/16 címet, és visszatartja az alapértelmezett útvonalat, így a belső név feloldódik, majd a kapcsolat lefagy. Az ellenkező eset ugyanilyen gyakori: az útvonal létezik, egy nyilvános feloldó NXDOMAIN-nel válaszol a privát névre, és a hibát útválasztási problémaként rögzítik. Az útvonal első tesztelése miatt olyan név útvonalait bámulja, amely soha nem oldódott volna fel.

Van egy harmadik kapu is, amelyet egyik fél sem fed le. Az átjárón lévő ACL, egy tűzfalszabály vagy egy kliensoldali szabályzat eldobhatja a kapcsolatot, miután mindkét döntés helyes volt. Amikor a név feloldódik, az útvonal létezik, és a kapcsolat mégis lejár, hagyja abba a DNS tesztelését.

Nevek és útvonalak tesztelése rögzített sorrendben

Válasszon sorrendet, és tartsa magát hozzá, különben azt a lépést kergeti, amelyik legutóbb meghiúsult. Oldja fel a dokumentált teljes belső nevet, erősítse meg, hogy a válasz olyan cím, amelyet az útválasztási tábla el tud vinni, majd ismételje meg egy nyilvános névvel annak bizonyítására, hogy az alagút nem fogott meg mindent. Egy systemd-gazdagépen a lekérdezés és a feloldó útválasztási tartománya egyetlen parancsnyira van egymástól:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

A Windows-ügyfél ugyanazt a két kérdést teszi fel más parancsokkal. A második azt a felületet jelenti, amelyet a rendszer valójában használna:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Ha a keresés címet ad vissza, és az útvonal-ellenőrzés a fizikai felületet nevezi meg, a névszabály működött, az útvonal nem. Ha a rövid név meghiúsul, miközben a teljes név feloldódik, az utótaglista a hibás, nem a feloldó.

Ahol az összehasonlítás általában félremegy

Az első hiba, hogy egy nem kapcsolódó nyilvános feloldótól kérdezünk privát névről, és az elutasítást a VPN-re vonatkozó bizonyítékként olvassuk. A második, hogy feltételezzük: egy működő nyilvános keresés bizonyítja az alagút feloldóútvonalát. A harmadik, hogy az osztott alagutat és az osztott DNS-t egyetlen tervezési döntésként kezeljük, holott egy telepítés lehet helyes az egyikben és hibás a másikban. Minden hiba magabiztos következtetéseket ad olyan tesztből, amely soha nem gyakorolta a kárhoztatott részt.

A saját biztonságos DNS-sel rendelkező böngésző megkerülheti a rendszerszabályt, ezért nem ellentmondás, hogy az egyik böngésző meghiúsul, míg a másik sikerül. A válaszoló feloldót hasonlítsa össze, ne a panaszkodó böngészőt.

Amint mindkét fél látható, a fennmaradó kérdés szabályzat kérdése, nem technikai: mely névterek tartoznak a szervezethez, ki birtokolja az egyes válaszokat, és melyeknek kellene egyáltalán elhagyniuk a gépet. Írja ezt a profil mellé, mert a szabályhoz következőként hozzányúló személynek szüksége lesz rá.