Кліентам 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. Запішыце ўсе тры вынікі ў тыкет змены, каб наступны чалавек пачаў з доказаў.