Заявката напуска машината и стига до домашния рутер, докато всеки пакет се тунелира. Естественият извод е липсващ маршрут, а маршрутът обикновено е наред. 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 за времетраенето на връзката. Както и да е, запишете списъка с резолвери преди и след повторно свързване, възстановете първоначалната метрика, когато приключите с тестовете, и потвърдете, че предишното поведение се върна.

Подобни статии