Padalintas DNS ir VPN: domeno taisyklės nėra IP maršrutai
Padalintas DNS sprendėją renkasi pagal vardą, o atsakymui vis tiek reikia maršruto. Testuokite domeno taisyklę ir kelią atskirai, platformoje, kurią iš tikrųjų naudojate.
Jūsų nešiojamasis kompiuteris išsprendžia intranet.corp per tunelį, o gitlab.com toliau eina pas teikėjo sprendėją, ir tai yra sąranka, kuri veikia taip, kaip suprojektuota. Ją sukūrė du atskiri sprendimai: vardų atitikimo taisyklė parinko sprendėją, o maršrutas grąžino atsakymą. Sulaužykite bet kurį iš jų ir naršyklė parodo gedimą, kuris iš išorės atrodo taip pat. Dauguma ataskaitų apie padalintą DNS aprašo antrąjį gedimą, kartu cituodamos įrodymus apie pirmąjį.
Dvi pusės gyvena skirtingose vietose ir paprastai jas redaguoja skirtingi žmonės. Viena yra DNS politika, prijungta prie VPN profilio, kita yra maršrutas, kurį tunelis įdiegia arba sulaiko. Derinimas sustoja, kai niekas nenustato, kuri pusė iš tikrųjų pasikeitė.
Du sprendimai, paslėpti vienoje užklausoje
Vardo pusė yra politikos objektas, o ne maršrutas. Windows tai vardų sprendimo politika VPN profilyje; Apple platformose atitikimo domenų rinkinys DNS nustatymų objekte; Linux tai maršrutizavimo domenas, padalinto sprendėjo eilutė arba vardų tarnybos perjungiklio tvarka. Kelio pusė yra įprastas maršrutizavimas, įdiegtas tunelio arba rankomis, ir jis neturi supratimo, kas yra pagrindinio kompiuterio vardas. Profilis, kuris leidžia priesagą, tik nusprendžia, kas atsakys; jis niekada nepadaro atsakymo pasiekiamo.
Greitas simptomų testas juos atskiria: pakeiskite vardą adresu. Jei adresas veikia, kelias tvarkingas, o taisyklė neteisinga. Jei adresas irgi nepavyksta, taisyklė gali būti teisinga, o kelio gali trūkti.
Kaip kiekviena platforma išreiškia tą pačią vardo taisyklę
Ketini yra toks pat, o laukų pavadinimai ne. Pavyzdys, nukopijuotas iš vieno kliento į kitą, išanalizuojamas švariai ir niekada nesutampa. Trys formos atrodo taip:
| 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 |
Atitikimo arba maršrutizavimo domenas yra priesagos testas, todėl intranet.corp apima git.intranet.corp ir neapima corp.intranet, o jo apvertimas yra dažniausia visos konfigūracijos klaida. Windows neša susiejimą kaip prie profilio prijungtą vardų sprendimo politiką, su savo prioritetų tvarka bet kokio sąsajos jau turėto priesagų sąrašo atžvilgiu. Apple platformos prijungia atitikimo domenus prie tinklo plėtinio DNS nustatymų objekto, o sistema juos taiko kiekvienam apribotam sprendėjui. Nė viena iš šių formų nėra maršrutas, ir nė viena negali padaryti nepasiekiamo adreso pasiekiamu. Windows vardų sprendimo politika nuoroda išvardija tos platformos laukų pavadinimus ir prioritetų taisykles, ir jos nėra tos, kurias naudoja Apple ar systemd dokumentai.
Teisingam atsakymui vis tiek reikia kelio
Sprendėjo atsakymas yra tik adresas, ir programa vis tiek turi jį pasiekti. Padalinto tunelio dizainas dažnai stumia 10.20.0.0/16 ir sulaiko numatytąjį maršrutą, todėl vidinis vardas išsprendžiamas, o ryšys tada pakimba. Priešingas atvejis taip pat dažnas: maršrutas yra, viešas sprendėjas į privatų vardą atsako NXDOMAIN, o gedimas registruojamas kaip maršrutizavimo problema. Pirmiau išbandžius kelią, jūs spoksote į maršrutus vardo, kuris niekada nebus išspręstas.
Yra ir trečiasis vartai, kurių neapima nė viena pusė. ACL šliuze, ugniasienės taisyklė arba kliento pusės politika gali numesti ryšį po to, kai abu sprendimai buvo teisingi. Kai vardas išsprendžiamas, maršrutas yra, o ryšys vis tiek baigiasi laiku, nustokite testuoti DNS.
Vardų ir kelių testavimas fiksuota tvarka
Pasirinkite tvarką ir laikykitės jos, kitaip veisitės paskutinį kartą nepavykusį žingsnį. Išspręskite dokumentuotą pilną vidinį vardą, patvirtinkite, kad atsakymas yra adresas, kurį gali nešti maršrutų lentelė, tada pakartokite su viešu vardu, kad įrodytumėte, jog tunelis nepagavo visko. systemd pagrindiniame kompiuteryje užklausa ir sprendėjo maršrutizavimo domenas yra vienos komandos atstumu:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows klientas užduoda tuos pačius du klausimus kitais cmdlet. Antrasis praneša sąsają, kurią sistema iš tikrųjų naudotų:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Jei paieška grąžina adresą, o kelio patikra įvardija fizinę sąsają, vardo taisyklė veikė, o maršrutas ne. Jei trumpas vardas nepavyksta, o pilnas išsprendžiamas, priesagų sąrašas neteisingas, o ne sprendėjas.
Kur palyginimas paprastai suklysta
Pirmoji klaida yra klausti nesusijusio viešo sprendėjo apie privatų vardą ir atsisakymą skaityti kaip įrodymą apie VPN. Antroji yra manyti, kad veikianti vieša paieška įrodo tunelio sprendėjo kelią. Trečioji yra traktuoti padalintą tuneliavimą ir padalintą DNS kaip vieną dizaino sprendimą, nors diegimas gali būti teisingas viename ir sugedęs kitame. Kiekviena klaida duoda užtikrintas išvadas iš testo, kuris niekada nepraktikavo kaltinamos dalies.
Naršyklė su savo saugiu DNS taip pat gali apeiti sistemos taisyklę, todėl tai, kad viena naršyklė nepavyksta, o kita pavyksta, nėra prieštaravimas. Palyginkite sprendėją, kuris atsakė, o ne naršyklę, kuri skundėsi.
Kai abi pusės matomos, likęs klausimas yra politikos, o ne techninis: kurios vardų erdvės priklauso organizacijai, kas valdo kiekvieną atsakymą ir kurios jų apskritai turėtų palikti mašiną. Užsirašykite tai prie profilio, nes kitam žmogui, kuris palies taisyklę, to prireiks.