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