Disigita DNS kaj VPN: domajnaj reguloj ne estas IP-itineroj

Via tekkomputilo solvas intranet.corp tra la tunelo, dum gitlab.com daŭre iras al la provizanta solvilo, kaj tio estas la aranĝo funkcianta laŭprojekte. Du apartaj decidoj produktis ĝin: nomkongrua regulo elektis la solvilon, kaj itinero reportis la respondon. Rompu iun ajn el la du kaj la foliumilo montras fiaskon, kiu de ekstere aspektas sama. Plej multaj raportoj pri disigita DNS priskribas la duan fiaskon, citante pruvojn pri la unua.

La du duonoj loĝas en malsamaj lokoj kaj kutime estas redaktataj de malsamaj homoj. Unu estas DNS-politiko alkroĉita al la VPN-profilo, la alia estas itinero, kiun la tunelo instalas aŭ retenas. Sensimulado haltas, kiam neniu konstatas, kiun duonon efektive moviĝis.

Du decidoj kaŝitaj en unu peto

La nomduono estas politika objekto, ne itinero. En Windows ĝi estas nomrezolva politiko sur la VPN-profilo; en Apple-platformoj aro da kongruaj domajnoj sur DNS-agorda objekto; en Linux itinerada domajno, disigita solvila linio aŭ la ordo de la nomserva ŝaltilo. La vojduono estas ordinara itinerado, instalita de la tunelo aŭ permane, kaj ĝi tute ne scias, kio estas gastigantnomo. Profilo, kiu allasas sufikson, nur decidas, kiu respondas; ĝi neniam igas la respondon atingebla.

Rapida simptomtesto apartigas ilin: anstataŭigu la nomon per adreso. Se la adreso funkcias, la vojo estas en ordo kaj la regulo malĝustas. Se ankaŭ la adreso malsukcesas, la regulo povas esti ĝusta kaj la vojo manki.

Kiel ĉiu platformo esprimas la saman nomregulon

La intenco estas identa kaj la kampnomoj ne. Ekzemplo kopiita de unu kliento al alia analiziĝas pure kaj neniam kongruas. La tri formoj aspektas tiel:

Kongrua aŭ itinerada domajno estas sufiksa testo, do intranet.corp kovras git.intranet.corp kaj ne kovras corp.intranet, kaj inversigi ĝin estas la plej ofta eraro en la tuta agordo. Windows portas la mapadon kiel nomrezolvan politikon alkroĉitan al la profilo, kun propra prioritata ordo kontraŭ iu ajn sufiksa listo, kiun la interfaco jam havis. Apple-platformoj alkroĉas kongruajn domajnojn al la DNS-agorda objekto de la reta etendaĵo, kaj la sistemo aplikas ilin laŭ ĉiu limigita solvilo. Neniu el ĉi tiuj formoj estas itinero, kaj neniu povas igi neatingeblan adreson atingebla. La referenco Windows-nomrezolva politiko listigas la kampnomojn kaj prioritatajn regulojn por tiu platformo, kaj ili ne estas tiuj, kiujn uzas la dokumentoj de Apple aŭ systemd.

Ĝusta respondo ankoraŭ bezonas vojon

Respondo de solvilo estas nur adreso, kaj la aplikaĵo ankoraŭ devas atingi ĝin. Disigita tunela dezajno ofte puŝas 10.20.0.0/16 kaj retenas la defaŭltan itineron, do la interna nomo solviĝas kaj la konekto poste pendas. La mala kazo estas same ofta: la itinero ekzistas, publika solvilo respondas la privatan nomon per NXDOMAIN, kaj la fiasko registriĝas kiel itinerada problemo. Testi la vojon unue lasas vin rigardi itinerojn por nomo, kiu neniam solviĝus.

Estas ankaŭ tria pordego, kiun neniu duono kovras. ACL sur la enirejo, fajroŝirma regulo aŭ klientflanka politiko povas forĵeti la konekton post kiam ambaŭ decidoj ĝustis. Kiam la nomo solviĝas, la itinero ekzistas kaj la konekto tamen tempas, ĉesu testi DNS.

Testi nomojn kaj vojojn en fiksa ordo

Elektu ordon kaj tenu ĝin, alie vi postkuros la paŝon, kiu lastatempe malsukcesis. Solvu la dokumentitan plenan internan nomon, konfirmu, ke la respondo estas adreso, kiun la itinerada tabelo povas porti, poste ripetu kun publika nomo por pruvi, ke la tunelo ne kaptis ĉion. Sur systemd-gastiganto la mendado kaj la itinerada domajno de la solvilo estas unu komando dise:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows-kliento demandas la samajn du demandojn per malsamaj cmdlet. La dua raportas la interfacon, kiun la sistemo efektive uzus:

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

Se la serĉo redonas adreson kaj la voja kontrolo nomas la fizikan interfacon, la nomregulo funkciis kaj la itinero ne. Se la mallonga nomo malsukcesas dum la plena solviĝas, la sufiksa listo malĝustas, ne la solvilo.

Kie la komparo kutime misas

La unua eraro estas demandi nerilatan publikan solvilon pri privata nomo kaj legi la rifuzon kiel pruvon pri la VPN. La dua estas supozi, ke funkcianta publika serĉo pruvas la solvilan vojon de la tunelo. La tria estas trakti disigitan tuneladon kaj disigitan DNS kiel unu dezajnan decidon, kvankam disfaldiĝo povas ĝusti en unu kaj rompiĝi en la alia. Ĉiu eraro produktas memfidajn konkludojn el testo, kiu neniam ekzercis la kulpigatan parton.

Foliumilo kun propra sekura DNS ankaŭ povas preterpasi la sisteman regulon, tial tio, ke unu foliumilo malsukcesas dum alia sukcesas, ne estas kontraŭdiro. Komparu la solvilon, kiu respondis, ne la foliumilon, kiu plendis.

Kiam ambaŭ duonoj videblas, la restanta demando estas politika kaj ne teknika: kiuj nomspacoj apartenas al la organizo, kiu posedas ĉiun respondon kaj kiuj el ili entute forlasu la maŝinon. Notu tion apud la profilo, ĉar la sekva persono, kiu tuŝos la regulon, bezonos ĝin.