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. Забележете ги трите резултати во тикетот за промена за следниот човек да почне од докази.