Kodėl privatūs DNS vardai nepavyksta VPN klientuose ir kur tikrinti
Privatūs vardai išsprendžiami tik tada, kai klientas pasitiki tavo rezolveriu, priesaga apibrėžta ir atsakymas gali grįžti per tunelį.
Atidarote nešiojamąjį kompiuterį viešbučio kambaryje, paleidžiate klientą, įrašote vidinio failų serverio vardą ir nieko negaunate. Tunelis praneša, kad prisijungta, o ping į adresą toje pačioje potinklyje vis dar atsako, tad pats transportas yra tvarkingas. Nepavyksta tik vardas, ir ši spraga susiaurina problemą iki dviejų vietų: kurio rezolverio klientas klausė ir ar gautas atsakymas gali grįžti per tunelį. Ištaisykite vieną ir praleiskite kitą, o gedimas tiesiog persikels.
Prieš redaguodami bet kurį profilį, patikrinkite, ką klientas daro su vardu. Linux sistemoje resolvectl query files.corp.example parodo, kuri sąsaja ir kuris rezolveris sukūrė atsakymą. Windows sistemoje Resolve-DnsName files.corp.example parodo serverį, kuris atsakė, ir adresą, kurią jis grąžino.
Perskaitykite atsakymą, prieš ką nors keisdami
Jei vardas grįžta kaip NXDOMAIN per kelias milisekundes, užklausa niekada nepasiekė jūsų zonos ir vietoj to atsakė koks nors viešas ar viešbučio rezolveris. Jei jis grįžta po ilgos pauzės, kažkas kelyje numeta UDP 53 prievadą ir klientas galiausiai perėjo prie atsarginio varianto. Jei jis atsako teisingu adresu, bet ryšys vis tiek stringa, paieška yra tvarkinga ir jūsų problema yra maršrutizavime arba pačioje paslaugoje.
Šis skaidymas į tris taupo valandą spėliojimų. Jis taip pat pasako, ar apskritai reikia liesti VPN: vardas, kuris išsprendžiamas į teisingą privatų adresą, jau įrodė rezolverio kelią, tad likęs darbas yra duomenų kelyje.
Išduokite rezolverį iš tunelio vidaus
Klientai skirstomi į dvi grupes. Vienai serveris gali nurodyti rezolverį jungties nustatymo metu; kita laiko nustatymą vietiniame faile, kurio jokia vartų sistema negali pakeisti nuotoliniu būdu.
OpenVPN priklauso pirmajai grupei. Serveryje push "dhcp-option DNS 10.8.0.53" ir push "dhcp-option DOMAIN corp.example" keliauja valdymo kanalu, bet tik jei kliento konfigūracijoje vis dar įjungtas pull. Rankiniu būdu redaguotas klientas su pull-filter ignore "dhcp-option" jų niekada nepamatys, ir ši viena eilutė paaiškina stebėtinai daug atvejų, kai serveris tai stumia, o mano nešiojamasis kompiuteris nesutinka.
WireGuard priklauso antrajai grupei, nes protokolas visiškai neturi parinkčių derinimo. Rezolveris ir paieškos domenas patenka į kliento [Interface] bloką kaip DNS = 10.8.0.53, corp.example. wg-quick tai pritaiko per resolvconf arba systemd-resolved, o Windows sistemoje oficialus klientas įdiegia NRPT taisykles, kurios egzistuoja tik tol, kol tunelis pakeltas: Get-DnsClientNrptPolicy jas išvardija, todėl tai greitas būdas pamatyti, ar klientas kada nors pritaikė jūsų failą.
IPsec/IKEv2 yra per vidurį. strongSwan attr įskiepis gali grąžinti DNS serverį, paimtą iš baseino, ir Windows klientas paprastai jį priima, bet profilis, kuris užfiksuoja savo vardų serverį, laimi prieš visa, ką siūlo vartai. Linux kliente lygiavertis rankinis veiksmas yra resolvectl dns wg0 10.8.0.53, po kurio seka resolvectl domain wg0 '~corp.example'; abu dingsta kartu su sąsaja, o tai yra būtent tai, ko norite su tuneliu susietam nustatymui.
Apibrėžkite priesagą, o ne prarykite kiekvieną užklausą
Nukreipti visą kliento rezolverių sąrašą į savo vidinį serverį yra paprasta ir dažniausiai neteisinga. Tada kiekvienas viešas vardas išsprendžiamas per jūsų duomenų centro išėjimą, CDN grąžina tolimus adresus, o vienas rezolverio gedimas nusineša ir naudotojo naršymą.
Siųskite į vidų tik privačią priesagą. systemd-resolved domenas, prasidedantis ~, yra skirtas tik maršrutizavimui, tad ~corp.example reiškia, kad užklausos pagal tą priesagą eina į tos sąsajos serverius, o visa kita toliau naudoja fizinį tinklą. Windows daro tą patį su NRPT taisyklėmis, apibrėžtomis vardų erdvei, o macOS su papildomu rezolverio failu /etc/resolver/ kataloge.
Daugiaadresiai vardai nusipelno savo atsakymo. .local vardai pagal konstrukciją yra link-local (RFC 6762), o taškas-taškas tun sąsaja neperneša tos daugiaadresės grupės, tad viešo rezolverio pridėjimas jų nepaskelbs, o paklausus vidinio unicast rezolverio, atsakymas bus NXDOMAIN. Reflektorius, pavyzdžiui, avahi reflektoriaus režimu, gali sujungti du segmentus, bet tai yra serverio pusės sprendimas, kurio joks klientas negali pareikalauti. Jei spausdintuvas ar NAS turi būti pasiekiamas vardu, suteikite jam A įrašą savo zonoje.
Įrodykite, kad atsakymas gali grįžti
Teisingas atsakymas, nurodantis nepasiekiamą adresą, atrodo lygiai kaip rezolverio problema, kol nepatikrinate maršruto. Paklauskite branduolio, kur atsakymas eitų: ip route get 10.20.5.20 įvardija sąsają ir, naudingiau, šaltinio adresą, kurią jis naudotų.
Stebėkite patį rezolverio adresą. Klientas su DNS = 10.8.0.53 šalia AllowedIPs = 10.20.0.0/16 siunčia savo užklausas per fizinę tinklo plokštę, kur jos tyliai miršta, nes rezolveris nėra jokiame prefikse, kurį tunelis reikalauja. Šis neatitikimas yra dažniausia vienos priežasties klaida visoje šioje srityje, ir jis lieka nematomas, nebent palygintumėte DNS nustatymą su leidžiamais prefiksais eilutė po eilutės.
Persidengiantys diapazonai sukelia priešingą gedimą. Atsakymas teisingas, maršrutas egzistuoja ir rodo netinkamą mazgą, nes 192.168.0.0/24 namuose yra konkretesnis nei tunelio maršrutas į tą patį diapazoną. Pernumeruokite vieną pusę arba išstumkite siauresnį maršrutą, tada patvirtinkite paslaugos mazgo ugniasienę ir grįžimo kelią; strongSwan pastabos apie peradresavimą apima to kelio sysctl pusę.
Sertifikatai yra atskiras tapatybės patikrinimas, kurį žmonės suverčia DNS. Jei naršyklė praneša apie vardo neatitikimą, o ne apie sprendimo klaidą, paieška jau veikė, o taisyti reikia sertifikato SAN. Tikrinkite HTTPS pagal vardą, niekada pagal pliką IP.
Tikrinkite dar kartą iš kliento, o ne iš vartų
Tikrinkite programoje, kuria skundžiasi naudotojas, nes paieška komandinėje eilutėje neįrodo, kad naršyklė eina tuo pačiu keliu. Chrome saugusis DNS ir Firefox network.trr.mode gali visiškai apeiti sistemos rezolverį, o kai tai daro, privatus vardas arba nepavyksta, arba nuteka viešam rezolveriui. resolvectl query palyginimas su rankiniu būdu paleistu dig @10.8.0.53 files.corp.example pasako, kuris iš dviejų įvyko.
Tada atsijunkite ir vėl prisijunkite, prieš vadindami tai sutvarkytu. Sąsajai rankiniu būdu nustatyti parametrai dingsta kartu su sąsaja, o profilis, kuris atrodė teisingai tik dėl pamiršto vietinio pakeitimo, žlugs kitą kartą paleidus.
Trumpas kontrolinis sąrašas kitai mašinai: vardas išsprendžiamas per tunelio rezolverį, priesaga apibrėžta, o ne globali, rezolverio adresas yra leidžiamų prefiksų viduje, atsakymo mazgas atsako paslaugos prievade, o sertifikatas apima naudotojo įrašytą vardą.