DNS i ndarë dhe VPN: rregullat e domenit nuk janë rrugë IP
DNS i ndarë zgjedh një zgjidhës sipas emrit, dhe përgjigja ka ende nevojë për një rrugë. Testoni rregullin e domenit dhe shtegun veçmas, në platformën që ekzekutoni vërtet.
Laptopi juaj e zgjidh intranet.corp përmes tunelit, ndërsa gitlab.com vazhdon të shkojë te zgjidhësi i ofruesit, dhe ky është rregullimi që funksionon siç është projektuar. Dy vendime të veçanta e krijuan: një rregull i përputhjes së emrit zgjodhi zgjidhësin, dhe një rrugë e ktheu përgjigjen. Thyeni cilindo prej tyre dhe shfletuesi tregon një dështim që nga jashtë duket i njëjtë. Shumica e raporteve për DNS të ndarë përshkruajnë dështimin e dytë, ndërsa citojnë prova për të parin.
Dy gjysmat jetojnë në vende të ndryshme dhe zakonisht redaktohen nga njerëz të ndryshëm. Njëra është politika DNS e lidhur me profilin VPN, tjetra është një rrugë që tuneli e instalon ose e mban. Diagnostikimi ngec kur askush nuk përcakton cila gjysmë lëvizi në të vërtetë.
Dy vendime të fshehura në një kërkesë
Gjysma e emrit është objekt politike, jo rrugë. Në Windows është politikë e zgjidhjes së emrave në profilin VPN; në platformat Apple një grup domenesh përputhjeje në një objekt cilësimesh DNS; në Linux një domen rrugëtimi, një rresht zgjidhësi të ndarë ose rendi i ndërprerësit të shërbimit të emrave. Gjysma e shtegut është rrugëtim i zakonshëm, i instaluar nga tuneli ose me dorë, dhe nuk e ka idenë se çfarë është emri i hostit. Një profil që lejon një prapashtesë vendos vetëm kush përgjigjet; nuk e bën kurrë përgjigjen të arritshme.
Një test i shpejtë simptomash i ndan: zëvendësoni emrin me një adresë. Nëse adresa funksionon, shtegu është në rregull dhe rregulli gabon. Nëse edhe adresa dështon, rregulli mund të jetë i saktë dhe shtegu mungon.
Si e shpreh secila platformë të njëjtin rregull emri
Qëllimi është identik dhe emrat e fushave nuk janë. Një shembull i kopjuar nga një klient në tjetrin analizohet pastër dhe nuk përputhet kurrë. Tre format duken kështu:
| 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 |
Një domen përputhjeje ose rrugëtimi është test prapashtese, prandaj intranet.corp mbulon git.intranet.corp dhe nuk mbulon corp.intranet, dhe përmbysja e kësaj është gabimi më i zakonshëm në të gjithë konfigurimin. Windows e mban hartëzimin si politikë të zgjidhjes së emrave të lidhur me profilin, me rendin e vet të përparësisë ndaj çdo liste prapashtesash që ndërfaqja kishte tashmë. Platformat Apple lidhin domenet e përputhjes me objektin e cilësimeve DNS të zgjerimit të rrjetit, dhe sistemi i zbaton ato për çdo zgjidhës të kufizuar. Asnjë nga këto forma nuk është rrugë, dhe asnjëra nuk mund ta bëjë një adresë të paarritshme të arritshme. Referenca politika e zgjidhjes së emrave në Windows rendit emrat e fushave dhe rregullat e përparësisë për atë platformë, dhe ato nuk janë ato që përdorin dokumentet e Apple ose systemd.
Një përgjigje e saktë ende ka nevojë për një shteg
Përgjigja e një zgjidhësi është vetëm një adresë, dhe aplikacioni duhet të arrijë akoma atje. Një projekt tuneli të ndarë shpesh shtyn 10.20.0.0/16 dhe mban rrugën e paracaktuar, kështu që emri i brendshëm zgjidhet dhe lidhja më pas varet. Rasti i kundërt është po aq i zakonshëm: rruga ekziston, një zgjidhës publik i përgjigjet emrit privat me NXDOMAIN, dhe dështimi regjistrohet si problem rrugëtimi. Testimi i shtegut së pari ju lë të shikoni rrugët për një emër që nuk do të zgjidhej kurrë.
Ekziston edhe një portë e tretë që asnjë gjysmë nuk e mbulon. Një ACL në portë, një rregull firewalls ose një politikë në anën e klientit mund ta hedhin lidhjen pasi të dy vendimet ishin të sakta. Kur emri zgjidhet, rruga ekziston dhe lidhja prapë skadon, ndaloni testimin e DNS.
Testimi i emrave dhe shtigjeve në një rend fiks
Zgjidhni një rend dhe mbani atë, përndryshe do të ndiqni hapin që dështoi i fundit. Zgjidhni emrin e plotë të brendshëm të dokumentuar, konfirmoni se përgjigja është një adresë që tabela e rrugëtimit mund ta mbajë, më pas përsëriteni me një emër publik për të provuar se tuneli nuk kapi gjithçka. Në një host systemd kërkesa dhe domeni i rrugëtimit të zgjidhësit janë një komandë larg njëri-tjetrit:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Një klient i Windows i bën të njëjtat dy pyetje me cmdlet të tjera. I dyti raporton ndërfaqen që sistemi do të përdorte në të vërtetë:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Nëse kërkimi kthen një adresë dhe kontrolli i shtegut përmend ndërfaqen fizike, rregulli i emrit funksionoi dhe rruga jo. Nëse emri i shkurtër dështon ndërsa emri i plotë zgjidhet, lista e prapashtesave është e gabuar dhe jo zgjidhësi.
Ku shkon zakonisht keq krahasimi
Gabimi i parë është të pyesësh një zgjidhës publik të palidhur për një emër privat dhe ta lexosh refuzimin si provë për VPN. I dyti është të supozosh se një kërkim publik që funksionon provon shtegun e zgjidhësit të tunelit. I treti është ta trajtosh tunelizimin e ndarë dhe DNS të ndarë si një vendim të vetëm projekti, ndërsa një vendosje mund të jetë e saktë në njërin dhe e prishur në tjetrin. Çdo gabim prodhon përfundime të sigurta nga një test që nuk e ushtroi kurrë pjesën e akuzuar.
Një shfletues me DNS të vetë sigurt mund të anashkalojë rregullin e sistemit, prandaj fakti që një shfletues dështon ndërsa tjetri ka sukses nuk është kontradiktë. Krahasoni zgjidhësin që u përgjigj, jo shfletuesin që u ankuan.
Pasi të dyja gjysmat të jenë të dukshme, pyetja e mbetur është pyetje politike dhe jo teknike: cilat hapësira emrash i përkasin organizatës, kush zotëron çdo përgjigje dhe cilat prej tyre duhet ta lënë makinën fare. Shkruajeni këtë pranë profilit, sepse personi tjetër që prek rregullin do t'i duhet.