VPN-клієнтам RRAS потрібен власний пул IPv4 і зворотний шлях

VPN-клієнт підключається й отримує адресу, але потрібний йому хост у LAN досі не може відповісти. У Windows Routing and Remote Access внутрішня адреса VPN-клієнтів надходить із пулу, налаштованого окремо від LAN-адаптера сервера, а стороні LAN потрібен маршрут назад до цього пулу. Дві зміни, а не одна, і вони зазнають невдачі по-різному. Пройдіть їх по порядку, щоб план адрес і зворотний шлях були доведені до виведення старих діапазонів.

Зарезервуйте діапазон до відкриття консолі

Виберіть префікс, який не перетинається з LAN, іншими діапазонами VPN чи будь-чим, що маршрутизується на майданчик. /24 — зручний розмір для тесту, і першу придатну частину можна віддати клієнтам, поки решта залишається вільною для зростання. Запишіть його разом із призначенням і власником, перш ніж вводити в консоль. Залиште місце на обох кінцях блоку, щоб пізніший поділ не змушував до перенумерації.

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

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

Зміна методу — це не додавання діапазону

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

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

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Другий cmdlet зазнає невдачі або створює непридатний пул, якщо сервер усе ще на призначенні DHCP. Перший замінює метод, а не розширює наявний пул. Жоден перегляд нічого не застосовує, тому запустіть відповідний, а потім підтвердьте отриманий пул у консолі. Якщо ви не впевнені, в якому стані сервер, прочитайте метод призначення на сторінці властивостей IPv4 і перелічіть налаштовані діапазони:

Get-VpnIPAddressRange

Метод DHCP із порожнім списком діапазонів означає, що застосовується перший перегляд. Статичний пул адрес із наявним діапазоном означає, що застосовується другий.

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

LAN потребує зворотного маршруту

Припустімо, LAN — це 10.60.0.0/24, а сервер RRAS — 10.60.0.10 у ній. Хосту в цій LAN, який відповідає клієнту в 10.250.50.0/24, потрібен шлях до пулу через сервер RRAS. Без цього шляху запит надходить, а відповідь гине.

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

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

Доведіть новий пул на одному пристрої, перш ніж виводити старий

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

Розв’язання імен заслуговує на окрему перевірку: доступ за IP може працювати, поки DNS клієнта досі вказує на резолвер, до якого він не дістає. DNS-сервер у LAN доступний лише тоді, коли клієнт має до нього маршрут і сервер приймає запити з нового діапазону. Обидва — часті проґавини під час перенесення пулу.

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

Перевірте результат трьома спостереженнями

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

З клієнта підтвердьте адресу й маршрут до одного хоста в LAN:

ipconfig | findstr /i "IPv4"
route print -4

З хоста в LAN підтвердьте зворотний шлях і політику за один прохід. Якщо ping не проходить, але застосунок працює, відсутній елемент — імовірно правило ICMP, а не маршрут. Якщо не проходить і те й те, прочитайте маршрут на хості, перш ніж редагувати VPN. Запишіть три результати в заявку на зміну, щоб наступна людина почала з доказів.