Dield DNS en VPN: domeinregels binne gjin IP-rûtes
Dield DNS kiest in resolver op namme, en it antwurd hat noch altyd in rûte nedich. Test de domeinregel en it paad apart, op it platfoarm dat jo echt brûke.
Jo laptop lost intranet.corp op fia de tunnel wylst gitlab.com nei de resolver fan de provider bliuwt gean, en dat is de opstelling dy't wurket sa't it ûntwurpen is. Twa aparte beslissingen makken dat: in namematchregel keas de resolver, en in rûte droech it antwurd werom. Brek ien fan beide en de browser lit in flater sjen dy't fan bûten itselde liket. De measte rapporten oer dield DNS beskriuwe de twadde flater wylst se bewiis oer de earste oanhelje.
De twa helten libje op ferskate plakken en wurde meast troch ferskate minsken bewurke. Ien is DNS-belied oan it VPN-profyl ferbûn, de oare is in rûte dy't de tunnel ynstallearret of tsjinhâldt. Debuggen stiet stil as nimmen fêststelt hokker helt eins ferhúze is.
Twa beslissingen ferstoppe yn ien fersyk
De nammehelt is in beliedsobjegoed, gjin rûte. Op Windows is it in namme-oplossingsbelied op it VPN-profyl; op Apple-platfoarmen in set matchdomeinen op in DNS-ynstellingsosje; op Linux in rûtesdomein, in dielde resolverrigel of de folchoarder fan 'e nammentsjinstskakel. De paadhelt is gewoane rûtering, troch de tunnel of mei de hân ynstallearre, en it hat gjin idee wat in hostnamme is. In profyl dat in efterheaksel tastiet, beslút allinnich wa't antwurdet; it makket it antwurd nea berikber.
In flugge symptoomtest skiedt se: ferfange de namme troch in adres. As it adres wurket, is it paad goed en de regel ferkeard. As it adres ek mislearret, kin de regel goed wêze en it paad ûntbrekke.
Hoe't elk platfoarm deselde nammeregel útdrukt
De bedoeling is identyk en de fjildnammen net. In foarbyld dat fan 'e iene klant nei de oare kopyeare wurdt, wurdt skjin parsearre en past nea. De trije foarmen sjogge der sa út:
| 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 |
In match- of rûtesdomein is in efterheakseltest, dus intranet.corp dekt git.intranet.corp en dekt corp.intranet net, en it omkearen dêrfan is de meast foarkommende flater yn 'e hiele opstelling. Windows draacht de mapping as namme-oplossingsbelied ferbûn oan it profyl, mei syn eigen foarrangoarder tsjin hokker efterheaksel list de ynterface al hie. Apple-platfoarmen ferbine matchdomeinen oan it DNS-ynstellingsosje fan 'e netwurkuoeffens, en it systeem past se ta per ôfbeakene resolver. Gjin fan dizze foarmen is in rûte, en gjinien kin in ûnberikber adres berikber meitsje. De referinsje Windows namme-oplossingsbelied listet de fjildnammen en foarrangregels foar dat platfoarm, en dat binne net dy't de Apple- of systemd-dokuminten brûke.
In goed antwurd hat noch altyd in paad nedich
In resolver-antwurd is allinnich in adres, en de applikaasje moat it noch berikke. In dield-tunnelûntwerp triuwt faak 10.20.0.0/16 en hâldt de standertrûte tsjin, dus de ynterne namme wurdt oplost en de ferbining hinget dan. It omkearde gefal is like gewoan: de rûte bestiet, in iepenbiere resolver antwurdet de priveenamme mei NXDOMAIN, en de flater wurdt as rûteringsprobleem registrearre. It paad earst testen lit jo stoarje nei rûtes foar in namme dy't nea oplost wurde soe.
Der is ek in tredde poarte dy't gjin helt dekt. In ACL op 'e gateway, in fjoerwâlregel of in kliïntsidebelied kin de ferbining falle litte nei't beide beslissingen goed wiene. As de namme oplost, de rûte bestiet en de ferbining dochs ferrint, stopje mei DNS testen.
Nammen en paden yn in fêste folchoarder testen
Kies in folchoarder en hâld dy oan, oars jeie jo efter de stap oan dy't it lêst mislearre. Los de dokumintearre folsleine ynterne namme op, befêstigje dat it antwurd in adres is dat de rûtetabel drage kin, en werhelje dan mei in iepenbiere namme om te bewizen dat de tunnel net alles fong. Op in systemd-host binne de fraach en it rûtesdomein fan 'e resolver ien opdracht fan elkoar:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10In Windows-klant stelt deselde twa fragen mei oare cmdlets. De twadde rapportearret de ynterface dy't it systeem eins brûke soe:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10As de syktocht in adres weromjout en de paadtests de fysike ynterface neamt, wurke de nammeregel en de rûte net. As de koarte namme mislearret wylst de folsleine namme oplost, is de efterheaksellist ferkeard en net de resolver.
Wêr't de ferliking meast misgiet
De earste flater is in net-relatearre iepenbiere resolver freegje oer in priveenamme en de wegering lêze as bewiis oer de VPN. De twadde is oannimme dat in wurkjende iepenbiere syktocht it resolverpaad fan 'e tunnel bewist. De tredde is dield tunneljen en dield DNS as ien ûntwerpbeslissing behannelje, wylst in ynset yn 'e iene goed en yn 'e oare stikken wêze kin. Elke flater leveret selsbetrouwen konklúzjes út in test dy't it beskuldige diel nea oefene hat.
In browser mei syn eigen feilige DNS kin de systeemregel ek omsile, dêrom is it gjin tsjinstelling as ien browser mislearret wylst in oare slagget. Ferlykje de resolver dy't antwurde, net de browser dy't klage.
Sadree't beide helten sichtber binne, is de oerbleaune fraach in beliedsfraach en net in technyske: hokker nammeromten hearre by de organisaasje, wa besit elk antwurd en hokker fan har moatte de masine hielendal ferlitte. Skriuw dat njonken it profyl, want de folgjende persoan dy't de regel oanrekket hat it nedich.