Дві VPN у Windows одночасно: який профіль зберігає маршрут за замовчуванням?

Підключіть другий тунель, і перший замовкає, хоча обидва клієнти досі повідомляють про здорове з’єднання. У Windows є лише один маршрут за замовчуванням, і кожен профіль, який його вимагає, забирає його в іншого. Симптом виглядає як збій VPN, але це боротьба за маршрутизацію між двома профілями. Вирішіть, який тунель має володіти цим маршрутом, і решта конфігурації піде за ним.

Найкращим маршрутом за замовчуванням може бути лише один запис

Таблиця маршрутизації IPv4 містить єдиний переможний маршрут для адресатів без точнішого збігу. Профіль VPN, який встановлює власний, замінює попередній одразу після підключення, і трафік, що раніше входив у перший тунель, тепер виходить через другий. Перший тунель залишається піднятим; зникає будь-який пакет, який використав би його для загальних адресатів.

Значки стану клієнта не можуть це показати. Вони повідомляють, що тунель встановлено, а не які префікси все ще спрямовуються до нього, тому користувач бачить два зелені значки й тайм-аут у якійсь програмі. Читання route print -4 під час збою інформативніше за будь-який журнал VPN.

Розв’язання імен — другий, незалежний конфлікт, і виправлення самої лише таблиці маршрутизації його не вирішить.

Що встановлює прапорець і що прибирає

Параметр міститься у властивостях адаптера кожного профілю VPN, у додаткових параметрах IPv4, і сформульований як використання шлюзу за замовчуванням у віддаленій мережі. Коли він увімкнений, кожне підключення додає маршрут за замовчуванням через тунель і ставить цей інтерфейс у чергу на загальний трафік. Коли вимкнений, Windows зберігає маршрут для власної підмережі тунелю й не чіпає решту таблиці.

Саме під час зняття прапорця більшість людей застрягає. Віддалений сайт зазвичай має більше одного префікса, і жоден із цих префіксів не лежить у підмережі адаптера, тому файлові сервери й адреси керування перестають відповідати. Прапорець не зламав тунель; він прибрав широкий маршрут, який покривав усе.

Змішані конфігурації законні та звичайні: корпоративний профіль зберігає прапорець як повний тунель, а лабораторний профіль розділено, щоб він не міг витіснити корпоративний маршрут за замовчуванням.

Обирайте за тим, що має нести кожен тунель

Три питання визначають розкладку. Чи має цей тунель нести звичайний інтернет-трафік, чи лише адреси в межах власного сайту? Чи використовують два сайти неперетинні приватні діапазони? І якщо профілем керує роботодавець, чи дозволено вам узагалі змінювати його поведінку маршрутизації?

Якщо один тунель має бути повним, він володіє маршрутом за замовчуванням, а другий має бути розділеним. Якщо жодному не потрібен загальний інтернет-трафік, зніміть прапорець на обох і дозвольте фізичному адаптеру зберегти маршрут за замовчуванням. Якщо діапазони перекриваються, зупиніться: 172.22.0.0/16 не може означати одну машину на корпоративному боці й іншу на боці лабораторії, і жоден прапорець цього не вирішить.

Запишіть рішення поряд з назвами профілів. Інакше третій VPN, доданий наступного кварталу, повторить розслідування з початку.

Додайте відсутні префікси й перевірте результат

Для кожного розділеного тунелю явно додайте віддалені діапазони, використовуючи адресу партнера, показану на цьому адаптері, замість публічної адреси сервера:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

Адаптер PPP використовує свою адресу партнера як наступний стрибок, а адаптер TAP зазвичай використовує шлюз, показаний на цьому інтерфейсі, тому читайте відомості про адаптер, а не копіюйте число з посібника. Додавайте постійний прапорець лише після того, як маршрут довів правильність, і видаляйте старі постійні записи перед додаванням замін. Керовані клієнти можуть встановлювати й захищати власні маршрути, і тоді зміну має зробити власник профілю.

DNS потребує окремого проходу. Обидва тунелі можуть нав’язувати резолвери, а Windows тримає список для кожного інтерфейсу з порядком переваги, тому ім’я з другої мережі може потрапити до резолвера першої. Подивіться, що кожен адаптер справді отримав, перш ніж обирати виправлення:

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

Політика розв’язання імен за доменом зазвичай краща за заміну глобального списку резолверів, бо цей список спільно використовує кожна програма на машині, і його тиха зміна переміщує не пов’язані запити.

Прийміть налаштування з чотирма перевірками: один ресурс у кожній віддаленій мережі, доступний за адресою, пошук імені в кожній із них, інтернет-маршрут за замовчуванням досі вказує на фізичний адаптер, і сеанс віддаленого робочого столу, який переживає підняття другого підключення.