Zergatik huts egiten dute DNS izen pribatuek VPN bezeroetan eta non egiaztatu

Hotel bateko gela batean ordenagailu eramangarria irekitzen duzu, bezeroa abiarazi, barneko fitxategi zerbitzariaren izena idatzi eta ez duzu ezer jasotzen. Tunelak konektaturik dagoela dio, eta azpisare berdineko helbide batera ping-ek oraindik erantzuten du, beraz garraioa bera ondo dago. Izenak soilik huts egiten du, eta hutsune horrek bi lekutara murrizten du arazoa: bezeroak zein ebazleri galdetu zion eta jasotako erantzunak tunelaren bidez itzultzeko aukera duen. Bat konpondu eta bestea albo batera utziz gero, hutsak leku aldatzeko besterik ez du egiten.

Edozein profil editatu aurretik, egiaztatu zer egiten duen bezeroak izenarekin. Linuxen, resolvectl query files.corp.example aginduak erakusten du zein esteka eta zein ebazlek sortu zuten erantzuna. Windowsen, Resolve-DnsName files.corp.example aginduak erantzun zuen zerbitzaria eta itzulitako helbidea erakusten ditu.

Irakurri erantzuna ezer aldatu aurretik

Izena NXDOMAIN gisa itzultzen bada milisekundu gutxitan, kontsultak ez zuen inoiz zure zona ukitu eta ebazle publiko edo hotel batek erantzun zuen haren ordez. Pausa luze baten ostean itzultzen bada, zerbait UDP 53 ataka ari da uzten bidean eta bezeroa erreserba batera erori zen azkenean. Helbide zuzenarekin erantzuten badu baina konexioak blokeatzen jarraitzen badu, bilaketak ondo dio eta zure arazoa bideratzean edo zerbitzuan bertan dago.

Hiruko banaketa horrek ordu bat aurrezten du susmo hutsean. Halaber, esango dizu VPN-a ukitu behar duzun ala ez: helbide pribatu zuzenarekin ebazten den izen batek jada frogatu du ebazlearen bidea, beraz geratzen den lana datuen bidean dago.

Banatu ebazlea tunelaren barrutik

Bezeroak bi taldetan banatzen dira. Bati zerbitzariak ebazle bat eman diezaioke konexioa ezartzean; besteak fitxategi lokal batean gordetzen du ezarpena, eta ez du inolako atebidek urrutitik aldatzerik.

OpenVPN lehen taldean dago. Zerbitzarian, push "dhcp-option DNS 10.8.0.53" eta push "dhcp-option DOMAIN corp.example" kontrol kanaletik jaisten dira, baina bezeroaren konfigurazioak pull aktibatuta badu soilik. Eskuz editaturiko bezero batek, pull-filter ignore "dhcp-option" badarama, ez ditu inoiz ikusiko, eta lerro bakar horrek «zerbitzariak bultzatzen du baina nire ordenagailuak ez dator bat» kasu harrigarri asko azaltzen ditu.

WireGuard bigarren taldean dago, protokoloak ez duelako aukeren negoziaziorik batere. Ebazlea eta bilaketa domeinua bezeroaren beraren [Interface] blokean sartzen dira, DNS = 10.8.0.53, corp.example gisa. wg-quick aplikazioak resolvconf edo systemd-resolved bidez aplikatzen du hori, eta Windowsen bezero ofizialak NRPT arauak instalatzen ditu tunela altxatuta dagoen bitartean soilik existitzen direnak: Get-DnsClientNrptPolicy aginduak zerrendatzen ditu, eta horrek azkar erakusten du bezeroak zure fitxategia inoiz aplikatu ote zuen.

IPsec/IKEv2 erdian dago. strongSwan-en attr pluginek igerileku batetik ateratako DNS zerbitzaria itzul dezake, eta Windows bezero batek normalean onartzen du, baina bere izen zerbitzaria finkatzen duen profil batek atebideak eskaintzen duen guztia gainditzen du. Linux bezero batean baliokide den eskuzko urratsa resolvectl dns wg0 10.8.0.53 da eta, ondoren, resolvectl domain wg0 '~corp.example'; biak interfazearekin batera desagertzen dira, eta horixe da tunelari lotutako ezarpen batentzat nahi duzuna.

Mugatu atzizkia kontsulta bakoitza irentsi beharrean

Bezeroaren ebazle zerrenda osoa barneko zerbitzarira zuzentzea erraza da eta ia beti okerra. Orduan izen publiko guztiak zure datu zentroaren irteeratik ebazten dira, CDNek urrutiko helbideak itzultzen dituzte eta ebazlearen matxura bakar batek erabiltzailearen nabigazioa eramaten du berarekin.

Bidali barrura atzizki pribatua soilik. systemd-resolved-en, ~ hasierako domeinu bat bideratzeko baino ez da, beraz ~corp.example esan nahi du atzizki horren azpiko kontsultak esteka horren zerbitzarietara joaten direla, eta gainerako guztiak sare fisikoa erabiltzen jarraitzen duela. Windowsek gauza bera egiten du izen espazio batera mugatutako NRPT arauekin, eta macek /etc/resolver/ azpiko ebazle fitxategi osagarri batekin.

Multicast izenek beren erantzuna merezi dute. .local izenak diseinuz link-local dira (RFC 6762) eta puntutik punturako tun interfazeak ez du multicast talde hori eramaten, beraz ebazle publiko bat gehitzeak ez ditu argitaratuko, eta barneko unicast ebazleren bati haiei buruz galdetzean NXDOMAIN itzuliko da. avahi bezalako islatzaile batek, islatzaile moduan, bi segmentu batu ditzake, baina hori zerbitzariaren aldeko erabakia da eta ezein bezerok ezin du eskatu. Inprimagailu edo NAS bat izenez eskuragarri egon behar bada, eman A erregistro bat zure zonan horren ordez.

Egiaztatu erantzunak itzultzeko aukera duela

Helbide iristezin batera zuzentzen den erantzun zuzen bat ebazlearen arazo bat bezala ikusten da ibilbidea egiaztatu arte. Galdetu nukleoari nora joango litzatekeen erantzuna: ip route get 10.20.5.20 aginduak interfazea eta, are erabilgarriago, erabiliko lukeen iturburu helbidea aipatzen ditu.

Zaindu ebazlearen helbidea bera. DNS = 10.8.0.53 ondoan AllowedIPs = 10.20.0.0/16 duen bezero batek bere kontsultak NIC fisikotik bidaltzen ditu, eta han isilean hiltzen dira, ebazlea ez dagoelako tunelak aldarrikatzen duen aurrizki batean ere. Desadostasun hori arlo oso honetako kausa bakarreko hutsegiterik ohikoena da, eta ikusezina da DNS ezarpena baimendutako aurrizkiekin lerroz lerro alderatzen ez badituzu.

Gainjarritako barrutiek aurkako hutsa eragiten dute. Erantzuna zuzena da, ibilbidea existitzen da, eta ostalari okerra seinalatzen du, zeren etxean 192.168.0.0/24 tunelaren barruti bererako ibilbidea baino zehatzagoa da. Zenbakitu berriro alde bat edo bultzatu ibilbide estuago bat, eta gero egiaztatu zerbitzu ostalariaren suebakia eta itzulera bidea; strongSwan-en birbidalketari buruzko oharrek bide horren sysctl aldea hartzen dute.

Ziurtagiriak jendeak DNSri egotzi ohi dion identitate egiaztapen bereizi bat dira. Nabigatzaileak ebazpen errore baten ordez izen desadostasuna ematen badu, bilaketa jada funtzionatu du eta ziurtagiriko SAN da zuzendu beharrekoa. Probatu HTTPS izenaren aurka, inoiz ez IP hutsaren aurka.

Probatu berriro bezerotik, ez atebidetik

Probatu erabiltzailea kexatzen den aplikazioaren barruan, zeren komando lerroko bilaketa batek ez du frogatzen nabigatzaileak bide bera hartzen duenik. Chrome-ren DNS seguruak eta Firefoxen network.trr.mode ezarpenak sistemaren ebazlea erabat saihets dezakete, eta hori egiten dutenean, izen pribatu batek huts egiten du edo ebazle publiko batera ihes egiten du. resolvectl query eta eskuz exekutatutako dig @10.8.0.53 files.corp.example alderatzeak esango dizu bietatik zein gertatu zen.

Ondoren, deskonektatu eta berriro konektatu konpondutzat eman aurretik. Interfaze bati eskuz ezarritako parametroak interfazearekin batera desagertzen dira, eta soilik ahaztutako tokiko aldaketa batengatik zuzena zirudien profil batek huts egingo du hurrengo abiaraztean.

Hurrengo makinarentzako zerrenda laburra: izena tunelaren ebazlearen bidez ebazten da, atzizkia mugatua da eta ez globala, ebazlearen helbidea baimendutako aurrizkien barruan dago, erantzuneko ostalariak zerbitzuaren atakan erantzuten du eta ziurtagiriak erabiltzaileak idatzitako izena hartzen du.