Jūsų skaidytas tunelis pasiekia programą, bet ne jos DNS serverį
Skaidytas tunelis gali maršrutizuoti programos potinklį ir vis tiek paleisti prie jo esantį rezolverį. Pridėkite maršrutą į hostą ir tada patikrinkite, kurį serverį Windows iš tikrųjų pasirenka.
Programos potinklio maršrutizavimas yra akivaizdi skaidyto tunelio dalis, ir tai ne visas darbas. Rezolveris dažnai būna kitame adrese nei programa, kuriai jis tarnauja, todėl veikiantis tunelis vis tiek gali palikti paiešką už jo ribų. Profilis, kuriame yra tik 10.80.0.0/16, siunčia 10.90.0.53 užklausą per vietinę sąsają, kur privačios zonos nėra. Pridėkite rezolverio kelią, tada pažiūrėkite į antrąją problemos pusę: kurį serverį klientas iš tikrųjų pasirenka.
Mitas: vienas maršrutas apima visą paslaugą
Skaidytas tunelis yra paskirties vietų, einančių per ryšį, sąrašas, o ne paslaugos aprašymas. Programos potinklis ir rezolverio adresas yra dvi paskirties vietos, ir profilis gali turėti vieną be kitos. Kai taip atsitinka, programa pasiekiama adresu, o jos vardas nepavyksta, kas atrodo kaip DNS gedimas, o ne maršrutizavimo spraga.
Potinklis aplink rezolverį taip pat nėra automatiškai padengtas. Maršrutas į hostą vienam adresui pakanka tam rezolveriui ir neatveria jo kaimynų. Tuo ir yra maršruto į hostą esmė: siauras pagal sumanymą ir lengvai užmirštamas, kai tame pačiame potinklyje atsiranda kita paslauga.
Kad paieška veiktų, turi būti trys dalykai: klientas maršrutizuoja rezolverio adresą per tunelį, šliuzas priima ir persiunčia tą užklausą, o rezolveris priima gaunamą šaltinį. Atsakymas taip pat turi grįžti sutartu keliu. Jei ko nors trūksta, simptomas tas pats, todėl verta užsirašyti adresų lentelę prieš liečiant konfigūraciją.
Nustatykite, kuriuos adresus profilis turi turėti
Išvardykite paskirties vietas eilės tvarka: programos tinklelį, rezolverio adresą ir viešą pabaigos tašką, kuris užbaigia patį tunelį. Trečioji niekada neturi būti maršrutizuojama į tunelį, nes išoriniam ryšiui reikia kelio, kuris egzistuoja prieš tunelį.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Įtraukite ir UDP, ir TCP DNS: tikimasi, kad realizacijos palaikys TCP šalia UDP, o užblokuotas TCP kelias duoda lėtus, dalinius gedimus, o ne švarius. Jei privati zona aptarnaujama ir per IPv6, atitinkama hosto išimtis naudoja IPv6 adresą ir priešdėlį ir yra atskiras įrašas.
Užsirašykite, ką profilis jau apima, prieš ką nors pridėdami. Pasikartojantis maršrutas nekenksmingas, bet netikėtas esamas maršrutas pasako, kad profilis suprojektuotas kitam adresų planui nei tas, kurį gavote.
Pridėkite maršrutą į hostą per ryšio savininką
Vietoje valdomam savajam Windows profiliui maršrutas priklauso ryšiui, o ne mašinos globaliai maršrutizavimo lentelei. Pirmiausia peržiūrėkite papildymą, tada pritaikykite jį ta pačia apimtimi, kurią naudoja profilis.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Pirmoji komanda peržiūri pakeitimą nieko neįdiegdama, o antroji išvardija maršrutus, kuriuos profilis šiuo metu turi. Microsoft Add-VpnConnectionRoute nuoroda dokumentuoja vieno naudotojo ir visų naudotojų apimtis; visų naudotojų profiliui reikia savo apimties parametro, o vieno naudotojo komanda visų naudotojų profiliui nepavyksta arba patenka ne į tą vietą.
Kai profilis valdomas arba gaunamas iš tiekėjo kliento, pakeitimas priklauso tam savininkui. Nuolatinio sistemos maršruto dėjimas ant ryšio politikos veikia tol, kol politika vėl pritaikoma ir maršrutas dingsta, o tai paprastai nutinka palaikymo skambučio metu, o ne testuojant. Tas gedimas tylus: maršrutas dingsta, vardas nustoja spręstis ir niekas nesieja dviejų įvykių. Įdėkite pakeitimą į savininko įrašą, kad kitas pakartotinis taikymas jį neštų, o ne ištrintų.
Po taikymo iš naujo prijunkite profilį, o ne manykite, kad maršrutas įsigaliojo. Maršruto pakeitimai aktyviame ryšyje ne visada užfiksuojami, o pakartotinis prisijungimas taip pat atkuria būseną, kurią jūsų naudotojai iš tikrųjų turės.
Patikrinkite, kurį rezolverį klientas iš tikrųjų naudojo
Maršrutas valdo paketus, adresuotus rezolveriui. Jis nenusprendžia, kuriuos vardus ten siųsti, ir tas pasirinkimas yra atskiras mechanizmas. Windows efektyvios vardų erdvės taisyklės gali pasirinkti rezolverį kiekvienam domenui, o profilio DNS nustatymai pateikia numatytąjį. Šie du sluoksniai gali nesutarti nesukeldami jokios klaidos, todėl tiesioginė užklausa yra tik pusė įrodymo.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Pirmoji komanda atspausdina galiojančią vardų erdvės politiką, o antroji tiesiogiai paklausia privataus rezolverio programos vardo. Tiesioginis atsakymas įrodo, kad kelias ir rezolveris veikia; jis neįrodo, kad pačios programos paieška pasirinko tą serverį. Palyginkite jį su įprasta to paties vardo paieška ir su atsakymu, kurį gauna programa.
Atsižvelkite į podėlius ir saugų DNS naršyklės lygmenyje, kuris gali visiškai apeiti sistemos rezolverį naudotojo įvestiems vardams. Paieškos priesaga yra dar viena klaidinga užuomina: ji išplečia trumpą vardą į visiškai kvalifikuotą ir neturi nieko bendra su tuo, kuris serveris atsako.
Pabaikite iš naujo prisijungdami ir pakartodami įprastą paiešką, tada patvirtinkite, kad įprastas naršymas vis dar laikosi patvirtintos politikos. Privataus rezolverio keitimas viešu tam, kad išsispręstų nesusijęs vardas, nėra pataisymas, ir jis tyliai perkelia privačias užklausas ten, kur jos niekada neturėjo patekti.