RRAS VPN klientams reikia savo IPv4 telkinio ir kelio atgal

VPN klientas prisijungia ir gauna adresą, bet jam reikalingas LAN mazgas vis tiek negali atsakyti. „Windows Routing and Remote Access“ VPN klientų vidinis adresas gaunamas iš telkinio, sukonfigūruoto atskirai nuo serverio LAN adapterio, o LAN pusei reikia maršruto atgal į tą telkinį. Du pakeitimai, ne vienas, ir jie nepavyksta skirtingais būdais. Atlikite juos iš eilės, kad adresų planas ir grįžimo kelias būtų įrodyti prieš išjungiant senus diapazonus.

Rezervuokite diapazoną prieš atidarydami konsolę

Pasirinkite priešdėlį, kuris nesutampa su LAN, kitais VPN diapazonais ar bet kuo, kas maršrutizuojama į svetainę. /24 yra patogus dydis testui, o pirmą naudingą dalį galima atiduoti klientams, kol likusi lieka laisva augimui. Užrašykite jį su paskirtimi ir savininku, prieš įvesdami į konsolę. Palikite vietos abiejuose bloko galuose, kad vėlesnis padalijimas nepriverstų pernumeruoti.

Adresų planas, gyvenantis tik konsolėje, yra vienas perstatymas nuo susidūrimo. Jis taip pat linkęs augti: kas nors vėliau prideda antrą diapazoną, ir niekas netikrina pirmojo. Laikykite planą šalia serverio dokumentacijos, o ne pokalbių gijoje.

Serverio LAN adapteris neapibrėžia šio telkinio. Viešo klausytojo keitimas arba adapterio pridėjimas prie LAN daro visiškai ką kita. Štai kodėl klientai gali prisijungti ir vis tiek gauti adresą iš netinkamos vietos. Telkinys gyvena serverio IPv4 savybėse, o ne adapterių sąraše.

Metodo keitimas nėra diapazono pridėjimas

RRAS turi priskyrimo metodą ir diapazonų rinkinį. Perėjimas nuo DHCP prie statinio telkinio yra metodo pakeitimas. Kito bloko pridėjimas, kai statinis telkinys jau aktyvus, yra diapazono pakeitimas.

Peržiūrėkite abi operacijas prieš vykdydami bet kurią, ir perskaitykite, kuri atitinka dabartinę serverio būseną:

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

Antroji cmdlet nepavyksta arba sukuria netinkamą telkinį, jei serveris vis dar naudoja DHCP priskyrimą. Pirmoji pakeičia metodą, o ne išplečia esamą telkinį. Nė viena peržiūra nieko netaiko, todėl paleiskite tinkamą, o tada patvirtinkite gautą telkinį konsolėje. Jei nesate tikri, kokioje būsenoje yra serveris, perskaitykite priskyrimo metodą IPv4 savybių puslapyje ir išvardykite sukonfigūruotus diapazonus:

Get-VpnIPAddressRange

DHCP metodas su tuščiu diapazonų sąrašu reiškia, kad taikoma pirmoji peržiūra. Statinis adresų telkinys su esamu diapazonu reiškia, kad taikoma antroji.

Atsižvelkite į paslaugos paleidimą iš naujo, kurio gali prireikti nustatymui, ir ne manykite, kad prisijungę klientai bus iš karto pernumeruoti. Klientas, kuris išlaiko seną adresą iki pakartotinio prisijungimo, elgiasi normaliai. Planuokite pakeitimą laiko langui, kai pakartotinis prisijungimas yra priimtinas.

LAN reikia maršruto atgal

Tarkime, LAN yra 10.60.0.0/24, o RRAS serveris yra 10.60.0.10 jame. To LAN mazgas, atsakantis klientui 10.250.50.0/24, turi turėti kelią į telkinį per RRAS serverį. Be šio kelio užklausa atvyksta, o atsakymas miršta.

Jei mazgo numatytoji tinklo sąsaja yra kitas maršrutizatorius, tam maršrutizatoriui reikia grįžimo maršruto VPN priešdėliui. Statinis maršrutas RRAS serveryje čia nepadeda; grįžimo kelias turi egzistuoti įrenginyje, kuriam priklauso LAN tinklo sąsaja, todėl pridėkite jį prie maršrutizavimo lentelės arba dinaminio maršrutizavimo proceso, priklausomai nuo to, ką naudoja svetainė.

Patikrinkite ir mazgo užkardą bei visas tinklo prieigos taisykles pagal naują šaltinio diapazoną. Taisyklės, parašytos senajam klientų diapazonui, atmeta naująjį, net jei priskyrimas pavyko. Kliento maršrutai į LAN ir DNS sprendimas yra atskiri reikalavimai, ir abu gali nepavykti, kol tunelis atrodo sveikas. Išbandykite kiekvieną atskirai.

Įrodykite naują telkinį viename įrenginyje, prieš išjungdami senąjį

Paimkite vieną jūsų kontroliuojamą autorizaciją, prisijunkite iš naujo ir perskaitykite telkinio adresą, kurį gavo klientas. Tas vienas skaičius atskiria priskyrimą nuo maršrutizavimo. Tada išbandykite įvardytą programą, stebėkite grįžtančias bangas ir pabandykite paskirties vietą, kuri turėtų likti uždrausta. Trys stebėjimai, trys skirtingi gedimo būdai.

Vardų sprendimas nusipelno atskiro bandymo: prieiga pagal IP gali veikti, kol kliento DNS vis dar rodo į sprendiklį, kurio jis negali pasiekti. DNS serveris LAN tinkle pasiekiamas tik tuo atveju, jei klientas turi maršrutą į jį ir serveris priima užklausas iš naujo diapazono. Abu yra dažnos spragos, kai telkinys perkeliamas.

Išjunkite senus diapazonus ir jų išimtis tik įvertinę aktyvias sesijas ir priežiūros procesą. Prisijungęs klientas su nauju adresu įrodo priskyrimą, o ne prieigos politiką. Laikykite seną diapazoną dokumentuotą, kol baigsis paskutinė jį naudojusi sesija.

Patikrinkite rezultatą trimis stebėjimais

Priėmimui reikia trijų faktų: klientas turi adresą iš naujo telkinio, LAN mazgas gali jį pasiekti ir gauti atsakymą, o uždrausta paskirties vieta tebėra uždrausta. Kiekvienas turi savo patikrą, todėl gedimas nurodo priskyrimą, maršrutizavimą arba politiką. Vykdykite juos ta tvarka.

Iš kliento pusės patvirtinkite adresą ir maršrutą į vieną LAN mazgą:

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

Iš LAN mazgo pusės patvirtinkite grįžimo kelią ir politiką vienu ėjimu. Jei ping nepavyksta, bet programa veikia, trūkstama dalis greičiausiai yra ICMP taisyklė, o ne maršrutas. Jei nepavyksta abu, perskaitykite maršrutą mazge prieš redaguodami VPN. Užrašykite tris rezultatus pakeitimo biliete, kad kitas žmogus pradėtų nuo įrodymų.