Podijeljeni DNS i VPN: pravila domena nisu IP rute

Vaš laptop razrješava intranet.corp kroz tunel, dok gitlab.com i dalje ide ka ISP-ovom razrješivaču, i to je postavka koja radi kako je projektovana. Dvije odvojene odluke su je stvorile: pravilo podudaranja imena odabralo je razrješivač, a ruta je vratila odgovor. Prekinite bilo koju od njih i pregledač pokazuje kvar koji spolja izgleda isto. Većina izvještaja o podijeljenom DNS-u opisuje drugi kvar dok citira dokaze o prvom.

Dvije polovine žive na različitim mjestima i obično ih uređuju različiti ljudi. Jedna je DNS politika vezana za VPN profil, druga je ruta koju tunel postavlja ili zadržava. Otklanjanje grešaka staje kada niko ne utvrdi koja se polovina zaista pomjerila.

Dvije odluke skrivene u jednom zahtjevu

Polovina imena je objekat politike, a ne ruta. Na Windowsu je to politika razrješavanja imena na VPN profilu; na Apple platformama skup domena podudaranja na objektu DNS postavki; na Linuxu domen rutiranja, linija podijeljenog razrješivača ili red usluge imena. Polovina puta je obično rutiranje, koje postavlja tunel ili ruka, i ono nema pojma šta je ime hosta. Profil koji dopušta sufiks samo odlučuje ko odgovara; nikada ne čini odgovor dostupnim.

Brzi test simptoma ih razdvaja: zamijenite ime adresom. Ako adresa radi, put je u redu, a pravilo je pogrešno. Ako i adresa ne uspije, pravilo može biti ispravno, a put nedostaje.

Kako svaka platforma izražava isto pravilo imena

Namjera je identična, a nazivi polja nisu. Primjer kopiran s jednog klijenta na drugi raščlanjuje se čisto i nikada se ne poklapa. Tri oblika izgledaju ovako:

Domen podudaranja ili rutiranja je test sufiksa, pa intranet.corp pokriva git.intranet.corp i ne pokriva corp.intranet, a okretanje toga je najčešća greška u cijeloj postavci. Windows nosi mapiranje kao politiku razrješavanja imena vezanu za profil, sa sopstvenim redom prioriteta prema bilo kojoj listi sufiksa koju je interfejs već imao. Apple platforme vezuju domene podudaranja za objekat DNS postavki mrežnog proširenja, a sistem ih primjenjuje po svakom ograničenom razrješivaču. Nijedan od ovih oblika nije ruta i nijedan ne može učiniti nedostupnu adresu dostupnom. Referenca Windows politika razrješavanja imena navodi nazive polja i pravila prioriteta za tu platformu, i to nisu ona koja koriste Apple ili systemd dokumenti.

Ispravan odgovor i dalje traži put

Odgovor razrješivača je samo adresa, a aplikacija do nje i dalje mora stići. Dizajn podijeljenog tunela obično gura 10.20.0.0/16 i zadržava zadanu rutu, pa se interno ime razriješi, a veza se zatim objesi. Suprotan slučaj je jednako čest: ruta postoji, javni razrješivač odgovara na privatno ime sa NXDOMAIN, a kvar se prijavljuje kao problem rutiranja. Testiranje puta prvo vas ostavlja da buljite u rute za ime koje se nikada ne bi razriješilo.

Postoji i treća kapija koju nijedna polovina ne pokriva. ACL na pristupniku, pravilo zaštitnog zida ili politika na strani klijenta mogu odbaciti vezu nakon što su obje odluke bile ispravne. Kada se ime razriješi, ruta postoji, a veza i dalje istekne, prestanite testirati DNS.

Testiranje imena i puteva u fiksnom redu

Odaberite red i držite ga se, inače ćete juriti korak koji je posljednji pao. Razriješite dokumentovano puno interno ime, potvrdite da je odgovor adresa koju tabela rutiranja može nositi, zatim ponovite s javnim imenom da dokažete da tunel nije sve zahvatio. Na systemd hostu upit i domen rutiranja razrješivača udaljeni su jednu komandu:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows klijent postavlja ista dva pitanja drugim cmdletima. Drugi izvještava interfejs koji bi sistem zaista koristio:

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

Ako pretraga vrati adresu, a provjera puta navede fizički interfejs, pravilo imena je radilo, a ruta nije. Ako kratko ime ne uspije dok se puno ime razrješava, lista sufiksa je pogrešna, a ne razrješivač.

Gdje poređenje obično pođe naopako

Prva greška je pitati nepovezani javni razrješivač o privatnom imenu i čitati odbijanje kao dokaz o VPN-u. Druga je pretpostaviti da uspješna javna pretraga dokazuje put razrješivača tunela. Treća je tretirati podijeljeno tuneliranje i podijeljeni DNS kao jednu projektnu odluku, dok raspoređivanje može biti ispravno u jednom i pokvareno u drugom. Svaka greška daje sigurne zaključke iz testa koji nikada nije vježbao dio koji se okrivljuje.

Pregledač sa sopstvenim sigurnim DNS-om takođe može zaobići sistemsko pravilo, zato što jedan pregledač pada dok drugi uspijeva nije protivrječnost. Uporedite razrješivač koji je odgovorio, a ne pregledač koji se požalio.

Kada su obje polovine vidljive, preostalo pitanje je pitanje politike, a ne tehničko: koji imenski prostori pripadaju organizaciji, ko posjeduje svaki odgovor i koji od njih uopšte treba da napuste mašinu. Zapišite to pored profila, jer će sljedećoj osobi koja dotakne pravilo to trebati.