DNS истекување кај Windows VPN: зошто метриката ја победува рутата

Барањето ја напушта машината и стигнува до домашниот рутер додека секој пакет се тунелира. Природниот заклучок е рута што недостига, а рутата обично е во ред. 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 за времетраењето на врската. Како и да е, запишете го списокот резолвери пред и по повторно поврзување, вратете ја оригиналната метрика кога ќе завршите со тестирање и потврдете дека претходното однесување се вратило.