Разделен тунел в Windows: кутията на шлюза и липсващият префикс

Windows праща всичко през тунела, докато не махнете една отметка, а след това твърде малко, докато не добавите подмрежата. И двете са част от една и съща промяна.

Тунелът съобщава, че е свързан, и уикито все още се зарежда. После едно изтегляне засича и споделената папка на рафта спира да отговаря. Тунелът си е свършил работата, а профилът просто е претендирал за всяка дестинация.

Windows третира VPN връзката като решение за маршрут. Докато това решение не се стесни, машината се държи така, сякаш се е преместила в офиса.

Защо работещ тунел се усеща като прекъсване

Профил, на който е разрешено да използва отдалечения шлюз, инсталира маршрут по подразбиране през тунела. Всяка дестинация, която не е на локалната връзка, след това излиза през офисната защитна стена. Локалните споделени папки спират да отговарят, защото трафикът им сега пътува до друг континент и обратно. Нищо в състоянието на клиента не отразява това.

Симптомите са объркващи нарочно. Разрешаването на имена може още да работи, докато споделената папка изтича по време, или обратното. Потребителят съобщава, че VPN е счупен, клиентът съобщава, че е наред, и двете твърдения са точни.

Отметката, скрита в диалога за IPv4

Настройката е на няколко диалога дълбочина. Отворете ncpa.cpl, щракнете с десния бутон върху връзката, после свойства на IPv4, после Разширени, и махнете опцията, която позволява на връзката да стане отдалечен шлюз по подразбиране. Тази една кутия решава дали профилът е пълен тунел. Всичко останало в профила продължава да важи.

Сравнете route print -4 преди и след повторното свързване. Записът 0.0.0.0, който преди сочеше към тунела, трябва да изчезне, а корпоративните префикси трябва да останат.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Промяната на метриката на интерфейса не е заместител. Метриката решава само между два конкуриращи се маршрута по подразбиране, а клиент, който при всяко свързване преинсталира своя маршрут по подразбиране, печели това състезание независимо от зададеното число.

Префиксът, който никой не е изброил

Разделеният тунел излага точно префиксите, записани в профила. Офис подмрежа, добавена след написването на профила, остава недостъпна, докато тунелът е напълно здрав. Тогава докладът пристига като един счупен сървър, а не като счупен VPN.

Добавен на ръка маршрут покрива празнината, докато адресът на шлюза се промени. Записването на префикса във връзката е по-устойчиво, защото префиксът тогава следва връзката, а не предполагаем адрес.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Четете запазения списък и живата таблица заедно. Запазен префикс може да съществува, докато таблицата никога не го получава, което се случва, когато агент за управление филтрира маршрути, след като връзката се вдигне. Обратното също се случва, с маршрут в регистъра, сочещ към адаптер, който е изключен. Никой от двата изгледа сам не разказва цялата история.

Доказване на резултата след рестарт

Проследете в двете посоки и решавайте по име. Публичното проследяване трябва да излиза през доставчика, вътрешното проследяване трябва да влиза в тунела, а вътрешен хост трябва да отговаря по име, а не само по адрес.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Повторете след прекъсване, повторно свързване и един рестарт. Префикс, който оцелява при ръчно повторно свързване и изчезва след рестарт, никога не е бил запазван в профила.

Дръжте принтера и NAS също в теста, защото разделен тунел, който отрязва устройствата до лаптопа, е решил един проблем, като е създал по-малък и по-дразнещ. Справката на Microsoft за Add-VpnConnectionRoute е мястото, където да сверите изписването на параметрите с версията на вашия модул.

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