Windows VPN-дегі DNS ағып кетуі: неге метрика маршруттан басым

Сұрау машинадан шығып, үй маршрутизаторына жетеді, ал әр пакет туннель арқылы өтіп жатыр. Табиғи қорытынды — жоғалған маршрут, ал маршрут әдетте дұрыс. Windows интерфейс метрикасы бойынша қай интерфейстің таратушысынан сұрауды таңдай алады, және туннель адаптері бұл салыстыруда сымсыз интерфейске жиі ұтылады.

Бір ағудың екі түсіндірмесі

Маршрут түсіндірмесі трафиктің бір бөлігі туннельден шығып кетеді дейді, сондықтан әдепкі маршрут немесе бөлінген туннель тізімі қате болуы керек. Бұл түсіндірмені бір командамен тексеруге болады, ал әдепкі маршрут туннельге сілтесе, мәселе жабылады. Оны бірінші тексеріңіз, өйткені арзан, содан кейін таза қайтқанда шетке қойыңыз.

Реттеу түсіндірмесі трафик толығымен туннельде дейді, ал сұрау әлі де басқа таратушыға жіберіледі. Windows таратушы таңдауын реті бар интерфейстік қасиет ретінде қарастырады, сондықтан метрикасы жақсырақ физикалық адаптер шешілген мекенжай пакеттері туннельмен жүрсе де, атау үшін DNS бере алады. Екі түсіндірме де ағу сынақ парағында бірдей симптом береді, сондықтан сынақ диагноз емес. Олардың тек біреуі ғана маршруттарды өңдеумен түзетіледі.

Метрикалар мен таратушыларды бірге салыстырыңыз

Туннель қосулы кезде интерфейстерді, олардың метрикаларын және конфигурацияланған серверлерін жазып алыңыз. Оларды екі бөлек тізім емес, кесте ретінде оқыңыз, өйткені сұрақ қай таратушы бірінші тұрғаны туралы, қандай таратушылар бар екені туралы емес.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Туннель адаптерінің саны физикалық адаптерден жоғары болса, оның таратушысы басымдық алмайды, және ішкі атау физикалық жақ ұсынған нәрсеге кетеді. Ол маршрутизатор кэштен жауап бере алады, сұрауды әрі жібере алады немесе одан бас тарта алады, және бұл нәтижелердің ешқайсысы сіз ойлаған жоба емес. Реттеу — басымдық, сондықтан ол қате шығармай, үнсіз ұтылады.

Ешбір таратушы конфигурацияланбаған туннель адаптері де сол дәрежеде кең тараған нұсқа. Клиент интерфейсті DNS итермей-ақ көтереді, сондықтан реттеу сұрағы тіпті туындамайды.

Туннельді жоғары көтеріп, қайта тексеріңіз

Жоғарылатылған қабықта туннель интерфейсіне ең төмен метриканы беріңіз немесе физикалық адаптердің мәнін көтеріңіз. Екеуі де интерфейс бойынша параметр және екеуі де қайтарылады, бұл алдында отырмауыңыз мүмкін машинаны өзгерткенде маңызды.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Өзгеріс бірден көрінеді, ал DNS клиенті мен басқа тұтынушылар бұрын қабылдаған таңдауды кэштейді. Сұрау нәтижесінен бірдеңе шығармас бұрын туннельді қайта қосыңыз немесе жүйені қайта іске қосыңыз. Тым ерте жүргізілген сынақ ескі мінез-құлықты қайталап, сәтсіз түзету сияқты көрінеді.

Содан кейін бір ішкі және бір ашық атауды сұрап, қай сервер жауап бергенін тексеріңіз. Microsoft-тың автоматты метрикалар туралы анықтамалық ең төмен мәннің неге басымдық алатынын және автоматты тағайындау қалай шығарылатынын түсіндіреді.

Оны қайта қосылуға төзімді етіңіз

Әр қосылымда қайта жасалатын адаптердегі қолмен қойылған метрика — жоғалатын параметр. Егер клиент интерфейсті қайта құрса, бұл қайта жазу қосылымнан кейінгі скриптті, саясатты немесе қосылым кезінде DNS-ке ие болатын клиент конфигурациясын қажет етеді.

Физикалық адаптерде статикалық конфигурацияланған серверлерде сол төзімділік мәселесі керісінше бар. Олар сол интерфейс үшін алынып тасталғанша жауап беруді жалғастырады, ал DHCP оларды келесі жалдаудан қайта толады, сондықтан оларды алып тастау — өлшеу, жобалау емес. Төзімді жоба — ішкі атаулар кеңістігі үшін атауларды шешу саясаты немесе қосылым ұзақтығына DNS-ті өзіне алатын клиент. Қалай болғанда да, қайта қосылудың алдында және кейін таратушылар тізімін жазыңыз, сынақты бітіргенде бастапқы метриканы қалпына келтіріңіз және бұрынғы мінез-құлық қайтқанын растаңыз.