Windows VPN-д буруу DNS сервер: метрик, холболтын дараалал эсвэл дагавар
Windows-ын гурван механизм DNS шийдэгчийг сонгодог бөгөөд тэд өөр өөрөөр бүтэлгүйтдэг. Нэрийн орон зайн хамрах хүрээ, дэлхийн дараалал эсвэл засвар дахин холболтыг даах эсэхээр шийд.
Windows клиент ажиллаж буй туннельтай, корпорацийн шийдэгчийг авч явсан байсан ч дотоод нэрийг гэрийн чиглүүлэгч рүү илгээж болно. Аль сервер хариулахыг гурван өөр механизм шийддэг бөгөөд тэд өөр өөрөөр бүтэлгүйтдэг. Гурвыг засах шаардлагагүй: шинж тэмдэг аль нь тоглоомд байгааг хэлнэ. Доорх шийдвэрийн мод хэдхэн минут зарцуулж, метрикийн өөрчлөлт, бүртгэлийн дахин эрэмбэлэлт, NRPT дүрэм нэг дор ирж хэн ч аль нь юу хийснийг мэдэхгүй болдог ердийн үр дүнгээс сэргийлдэг.
Гурван механизм шийддэг, ихэвчлэн нэг нь буруу
Интерфейсийн метрик тодорхой хаягийн гэр бүлд зориулж адаптеруудыг эрэмбэлдэг. Tcpip\Linkage-ийн дор байх холболтын дараалал нь хуучин кодын замууд хараахан асуудаг машины түвшний интерфейсийн таних тэмдэгүүдийн жагсаалт юм. Нэрийн шийдлийн бодлогын хүснэгт (NRPT) нэрийн орон зайг тодорхой серверүүдэд холбодог, дагаварын жагсаалт богино нэрийг ер нь өргөтгөх эсэхийг шийддэг. Тэд харилцан хамааралгүй, тиймээс VPN адаптер дээрх зөв шийдэгч өөр газар байх хуучирсан давуу эрхэд хожигддог.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
Эдгээр механизмын аль нь ч туннелийн ард тал биш. VPN-ээс түлхэж буй сервер нэрийг шийдэж чадахгүй бол клиентийн талын бүх тохиргоо зөвхөн чимэглэл, тиймээс эхний шийдвэр нь шийдэгч өөрөө шууд асуухад хариулах боломжтой эсэх юм.
Нэгдүгээр шийдвэр: түлхэгдсэн шийдэгч ер нь хариулах боломжтой юу?
Серверээс тодорхой асууж, энгийн хайлттай харьцуул. Хариултуудын хоорондох зөрүү сонголтын асуудлыг хүрэх боломжийн асуудлаас тусгаарладаг бөгөөд энд хамгийн хурдан салаа энэ юм:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type AЭхнийх нь амжилттай, хоёр дахь нь бүтэлгүйтвэл шийдэгч хүрэх боломжтой бөгөөд Windows буруу сонгож байна; доорх нэрийн орон зай, дарааллын шийдвэр рүү яв. Эхнийх нь ч бүтэлгүйтвэл клиент дээр юу ч тус болохгүй: UDP болон TCP 53 туннелээр серверт хүрч байгаа эсэх, сервер дээрх хост галт хана сангаас хаяж байгаа эсэх, серверийн өөрийн дамжуулагчид эрүүл эсэхийг шалга.
Энэ салаанд зогс. Хүрч чадахгүй шийдэгчид NRPT дүрэм хэрэглэх нь мөн тэр алдааг илүү буцаах тохиргоотойгоор өгч, жинхэнэ гэмтлийг эрх мэдэлтэй харагдах дүрмийн ард нуудаг.
Хоёрдугаар шийдвэр: нэг нэрийн орон зай юу эсвэл асуулт бүр үү?
Хамрах хүрээ хэрэгслийг шийддэг. Зөвхөн корпорацийн нэрс бүтэлгүйтвэл машиныг дахин эрэмбэлэхийн оронд нэрийн орон зайг холбо: NRPT дүрэм тэр дагаварыг туннелийн шийдэгч рүү илгээж, бусад бүхнийг тайван орхино. Хайлт бүр өртсөн бол асуудал нь адаптеруудын дэлхийн давуу эрх, метрик нь эхлэх газар, учир нь энэ нь серверийн ямар ч тохиргоог өөрчлөхгүй.
Метрикийг хаягийн гэр бүл бүрд, хоёр интерфейс дээр тогтоож, дараа нь дарааллыг баталгаажуул:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv611-ийг дээрх мөрний туннелийн адаптерын ifIndex-ээр соль; хэрэв 11 нь LAN адаптер бол мөн тэр тушаал буруу замыг буулгана. Харин LAN адаптерыг өргөвөл нөгөө талаас мөн тэр дарааллд хүрнэ: netsh int ip set interface interface="Ethernet" metric=15, хоёр дахь гэр бүлд netsh int ipv6 set interface interface="Ethernet" metric=15, учир нь int ip зөвхөн IPv4-д хүрдэг.
Холболтын дараалал бол эхний алхам биш, хамгийн сүүлийн арга. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage төхөөрөмжийн таних тэмдэгүүдийн Bind жагсаалтыг хадгалдаг бөгөөд туннелийн таних тэмдгийг урд гаргах нь аль адаптерыг эхэлж асуухыг үнэхээр өөрчилдөг ч энэ нь нэрийн орон зай тус бүрийн хамрах хүрээгүй, машины түвшний бүртгэлийн утга юм. Засахаас өмнө экспортолж, дараа нь туннелийг дахин холбо, ингэснээр дараалал клиентийн хүлээж буй төлөвт үйлчилнэ.
Нэг нэрийн орон зайд нарийн хэрэгслийг илүүд үз:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersГуравдугаар шийдвэр: засвар дахин холболтыг даах уу?
Дараагийн утсан холболтын дахин холболт хүртэл ажиллах метрик хэзээ ч хадгалагдаагүй. L2TP/IPsec болон бусад холболтын профайлууд холболт эхлэхэд дахин үүсдэг тул хадгалагдсан утга утасны дэвтрийн бичлэгт IpInterfaceMetric хэлбэрээр амьдардаг, зөвхөн амьд интерфейс дээр биш. Зарим орчин тэр талбарыг яг энэ шалтгаанаар скриптээр бичдэг; бусад нь удирдлагын бодлогоос давуу эрхийг түлхэж, төгсгөлийн цэгийг тайван орхидог.
Кэш болон бүртгэл нь тусдаа давхарга. Туннель өргөгдсөний дараа эдгээрийг ажиллуулах нь хуучирсан бичлэгийг засч, клиентийг дахин бүртгэдэг боловч аль нь ч адаптерыг дахин эрэмбэлдэггүй:
ipconfig /registerdns
ipconfig /flushdnsМөн тэр давхаргад унтраалга байна. Физик адаптер дээр динамик бүртгэлийг унтраах нь клиент өөрийн VPN талын хаягийг буруу нэрээр зарлахаас сэргийлдэг бөгөөд энэ нь дээрх шинэчлэлээс өөр засвар юм.
IPv6 шийдвэрт өөрийн гэсэн мөр хүртэх ёстой. Физик адаптер дэлхийн IPv6 хаягтай байхад туннель зөвхөн IPv4 зөөдөг бол Windows нэрийн шийдэлд туннельгүй замыг илүүд үзэж болно. Тэр гэр бүлийг тусад нь шалга, учир нь IPv4-д тавьсан метрик түүний тухай юу ч хэлэхгүй:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricLAN адаптер дээр IPv6-г унтраах нь тэр замыг болон түүнтэй хамт протоколыг арилгана; IPv6 интерфейс дээрх метрикийн өөрчлөлт эсвэл корпорацийн нэрийн орон зайд зориулсан NRPT дүрэм нь гэр бүлийг хадгалж, давуу эрхийг засна. Тэр холбоос IPv6-гүй байх ёстой гэж шийдээгүй бол нарийныг сонго.
Нэрлэсэн эх сурвалжтай баталгаажуулж, нэг эзэмшигчтэй бай
Хуудас ачаалж байгаа эсэхээс гадна аль эх сурвалж хүчинтэй байгааг мэдээлдэг хэрэгслээр баталгаажуул:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type AДараа нь шүүлтийг сонголтоос тусгаарла, учир нь программын дотроос хоёулаа ижил харагдана. OpenVPN-ийн block-outside-dns бусад адаптер дээр 53 портыг хаадаг; энэ нь шийдэгч сонгодоггүй. Одоо асуулт бүр бүтэлгүйтвэл шүүлт цор ганц хүрэх боломжтой серверийг хааж байж болно; тохируулсан шийдэгчийг үл тоомсорловол дараалал эсвэл нэрийн орон зайн дүрэм буруу. Хоёулыг зэрэг өөрчлөх нь хаагдсан асуулт болон үл тоомсорлосон асуултыг ялгах боломжгүй болгоно.
DNS бодлогын нэг эзэмшигчтэй бай: VPN профайл, удирдлагын бодлого эсвэл NRPT дүрэм, тэдгээрийн хоёр нь биш. Хаахаас өмнө:
- Түлхэгдсэн шийдэгч тодорхой нэрлэгдэхэд хариулдаг, энгийн хайлт түүнийг ашигладаг.
- Таны өөрчилсөн дүрэм эсвэл метрик нь асуултуудыг үнэхээр зөөж буй хаягийн гэр бүлийг хамардаг.
- Тохиргоо таслалт болон дахин холболтыг даадаг, эсвэл та үүнийг хадгалсан профайл руу зөөсөн.
- Яг нэг механизм эрх мэдэлтэй, бусад нь байсан хэвээрээ орхигдсон.
Дарааллыг дуусгах зүйл биш, орчны төлөв гэж үз. Дахин холболтын дараа болон сүлжээний стекид хүрэх Windows шинэчлэлийн дараа дахин шалга, учир нь аль аль нь физик адаптерыг дахин урд гаргаж болно.