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 жаңыртуусунан кийин аны кайра текшериңиз, анткени экөөнүн кайсынысы болбосун физикалык адаптерди кайра алдыга чыгарышы мүмкүн.