Sadalīts DNS un VPN: domēna noteikumi nav IP maršruti
Sadalīts DNS izvēlas atrisinātāju pēc nosaukuma, un atbildei joprojām vajag maršrutu. Pārbaudiet domēna noteikumu un ceļu atsevišķi, platformā, kuru patiešām lietojat.
Jūsu klēpjdators atrisina intranet.corp caur tuneli, kamēr gitlab.com turpina iet uz pakalpojumu sniedzēja atrisinātāju, un tā ir kārtība, kas darbojas kā projektēta. To radīja divi atsevišķi lēmumi: nosaukumu atbilstības noteikums izvēlējās atrisinātāju, un maršruts atnesa atbildi atpakaļ. Salauziet jebkuru no tiem, un pārlūks parāda kļūmi, kas no ārpuses izskatās vienāda. Lielākā daļa ziņojumu par sadalītu DNS apraksta otro kļūmi, vienlaikus citējot pierādījumus par pirmo.
Abas puses dzīvo dažādās vietās, un tās parasti rediģē dažādi cilvēki. Viena ir DNS politika, kas pievienota VPN profilam, otra ir maršruts, ko tunelis instalē vai aiztur. Atkļūdošana apstājas, kad neviens nenustata, kura puse patiesībā pārvietojās.
Divi lēmumi, kas paslēpti vienā pieprasījumā
Nosaukuma puse ir politikas objekts, nevis maršruts. Windows tā ir nosaukumu atrisināšanas politika VPN profilā; Apple platformās atbilstības domēnu kopa DNS iestatījumu objektā; Linux tā ir maršrutēšanas domēns, sadalīta atrisinātāja rinda vai nosaukumu servisa pārslēga secība. Ceļa puse ir parasta maršrutēšana, ko instalē tunelis vai ar roku, un tai nav ne jausmas, kas ir resursdatora nosaukums. Profils, kas pieļauj sufiksu, tikai izlemj, kas atbildēs; tas nekad nepadara atbildi sasniedzamu.
Ātrs simptomu tests tos šķir: aizstājiet nosaukumu ar adresi. Ja adrese darbojas, ceļš ir kārtībā un noteikums ir nepareizs. Ja arī adrese neizdodas, noteikums var būt pareizs un ceļa var trūkt.
Kā katra platforma izsaka to pašu nosaukuma noteikumu
Nodoms ir identisks, un lauku nosaukumi nav. Piemērs, kas nokopēts no viena klienta uz otru, tiek parsēts tīri un nekad nesakrīt. Trīs formas izskatās šādi:
| 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 |
Atbilstības vai maršrutēšanas domēns ir sufiksa tests, tāpēc intranet.corp aptver git.intranet.corp un neaptver corp.intranet, un tā apgriešana ir visbiežākā kļūda visā konfigurācijā. Windows nes kartējumu kā profilam pievienotu nosaukumu atrisināšanas politiku ar savu prioritāšu secību pret jebkuru sufiksu sarakstu, kas saskarnei jau bija. Apple platformas pievieno atbilstības domēnus tīkla paplašinājuma DNS iestatījumu objektam, un sistēma tos piemēro katram ierobežotajam atrisinātājam. Neviena no šīm formām nav maršruts, un neviena nevar padarīt nesasniedzamu adresi sasniedzamu. Windows nosaukumu atrisināšanas politika uzziņa uzskaita šīs platformas lauku nosaukumus un prioritāšu noteikumus, un tie nav tie, ko izmanto Apple vai systemd dokumenti.
Pareizai atbildei joprojām vajag ceļu
Atrisinātāja atbilde ir tikai adrese, un lietojumprogrammai tā joprojām ir jāsasniedz. Sadalīta tuneļa dizains bieži iegrūž 10.20.0.0/16 un aiztur noklusējuma maršrutu, tāpēc iekšējais nosaukums tiek atrisināts, un savienojums pēc tam uzkaras. Pretējais gadījums ir tikpat biežs: maršruts ir, publisks atrisinātājs atbild uz privāto nosaukumu ar NXDOMAIN, un kļūme tiek reģistrēta kā maršrutēšanas problēma. Pārbaudot ceļu vispirms, jūs skatāties uz maršrutiem nosaukumam, kas nekad netiks atrisināts.
Ir arī trešie vārti, ko nenosedz neviena puse. ACL uz vārtejas, ugunsmūra noteikums vai klienta puses politika var nomest savienojumu pēc tam, kad abi lēmumi bija pareizi. Kad nosaukums tiek atrisināts, maršruts ir, un savienojums tomēr beidzas pēc laika, pārtrauciet testēt DNS.
Nosaukumu un ceļu testēšana fiksētā secībā
Izvēlieties secību un ievērojiet to, citādi jūs dzenaties pēc soļa, kas neizdevās pēdējais. Atrisiniet dokumentēto pilno iekšējo nosaukumu, apstipriniet, ka atbilde ir adrese, ko var nest maršrutu tabula, pēc tam atkārtojiet ar publisku nosaukumu, lai pierādītu, ka tunelis nevisu satvēra. systemd resursdatorā vaicājums un atrisinātāja maršrutēšanas domēns ir vienas komandas attālumā:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows klients uzdod tos pašus divus jautājumus ar citām cmdlet komandām. Otrā ziņo par saskarni, ko sistēma faktiski izmantotu:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Ja meklēšana atgriež adresi un ceļa pārbaude nosauc fizisko saskarni, nosaukuma noteikums darbojās, bet maršruts ne. Ja īsais nosaukums neizdodas, kamēr pilnais tiek atrisināts, nepareizs ir sufiksu saraksts, nevis atrisinātājs.
Kur salīdzinājums parasti nogāž greizi
Pirmā kļūda ir jautāt nesaistītam publiskam atrisinātājam par privātu nosaukumu un lasīt atteikumu kā pierādījumu par VPN. Otrā ir pieņemt, ka strādājoša publiska meklēšana pierāda tuneļa atrisinātāja ceļu. Trešā ir uzskatīt sadalītu tuneļošanu un sadalītu DNS par vienu dizaina lēmumu, lai gan izvietojums var būt pareizs vienā un salauzts otrā. Katra kļūda dod pārliecinātus secinājumus no testa, kas nekad nav praktizējis apsūdzēto daļu.
Pārlūks ar savu drošo DNS arī var apiet sistēmas noteikumu, tāpēc tas, ka viens pārlūks neizdodas, kamēr otrs izdodas, nav pretruna. Salīdziniet atrisinātāju, kas atbildēja, nevis pārlūku, kas sūdzējās.
Kad abas puses ir redzamas, atlikušais jautājums ir politikas, nevis tehnisks jautājums: kuras nosaukumu telpas pieder organizācijai, kam pieder katra atbilde un kurām no tām vispār vajadzētu pamest mašīnu. Pierakstiet to blakus profilam, jo nākamajam cilvēkam, kas aiztiks noteikumu, tas būs vajadzīgs.