RRAS VPN-kliënte het hul eie IPv4-poel en ’n pad terug nodig

Die VPN-kliënt maak verbinding en ontvang ’n adres, en die LAN-gasheer wat dit nodig het, kan dit steeds nie antwoord nie. In Windows Routing and Remote Access kom die binne-adres vir VPN-kliënte uit ’n poel wat apart van die bediener se LAN-adapter opgestel word, en die LAN-kant het ’n roete terug na daardie poel nodig. Twee veranderinge, nie een nie, en hulle misluk op verskillende maniere. Werk hulle in volgorde deur sodat die adresplan en die terugpad bewys is voordat ou reekse uit diens onttrek word.

Reserveer die reeks voordat jy die konsole oopmaak

Kies ’n voorvoegsel wat nie die LAN, ander VPN-reekse of enigiets wat na die terrein gerouteer word, oorvleuel nie. ’n /24 is ’n gerieflike grootte vir ’n toets, en die eerste bruikbare deel kan aan kliënte gegee word terwyl die res vir groei vry bly. Skryf dit met sy doel en eienaar neer voordat jy dit in ’n konsole intik. Laat ruimte aan beide kante van die blok sodat ’n latere splitsing nie ’n hernommering afdwing nie.

’n Adresplan wat net in ’n konsole leef, is een heropbou van ’n botsing af. Dit is ook geneig om te groei: iemand voeg later ’n tweede reeks by en niemand kontroleer die eerste nie. Hou die plan langs die bedienerdokumentasie, nie in ’n gespreksdraad nie.

Die bediener se LAN-adapter definieer nie hierdie poel nie. Om die publieke luisteraar te verander of ’n adapter by die LAN te voeg, doen heeltemal iets anders. Dit is waarom kliënte kan verbind en steeds ’n adres van die verkeerde plek ontvang. Die poel leef in die bediener se IPv4-eienskappe, nie in die adapterlys nie.

Om die metode te verander is nie om ’n reeks by te voeg nie

RRAS het ’n toewysingsmetode en ’n stel reekse. Om van DHCP na ’n statiese poel te skuif is ’n metodeverandering. Om nog ’n blok by te voeg terwyl die statiese poel reeds aktief is, is ’n reeksverandering.

Voorskou albei bewerkings voordat jy enige een uitvoer, en lees watter een by die bediener se huidige toestand pas:

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

Die tweede cmdlet misluk of lewer ’n onbruikbare poel as die bediener nog op DHCP-toewysing is. Die eerste vervang die metode eerder as om ’n bestaande poel uit te brei. Nie een voorskou pas enigiets toe nie, so voer die een uit wat pas en bevestig dan die resulterende poel in die konsole. As jy onseker is in watter toestand die bediener is, lees die toewysingsmetode op die IPv4-eienskappeblad en lys die opgestelde reekse:

Get-VpnIPAddressRange

’n Metode van DHCP met ’n leë reekslys beteken die eerste voorskou pas toe. Statiese adrespoel met ’n bestaande reeks beteken die tweede doen dit.

Reken vir die diensherstarting wat die instelling mag vereis, en moenie aanneem dat verbinde kliënte dadelik hernommer word nie. ’n Kliënt wat sy ou adres hou totdat hy weer verbind, tree normaal op. Beplan die verandering vir ’n venster waarin ’n herverbinding aanvaarbaar is.

Die LAN het ’n roete terug nodig

Veronderstel die LAN is 10.60.0.0/24 en die RRAS-bediener is 10.60.0.10 daarop. ’n Gasheer op daardie LAN wat aan ’n kliënt in 10.250.50.0/24 antwoord, het ’n pad na die poel deur die RRAS-bediener nodig. Sonder daardie pad kom die versoek aan en sterf die antwoord.

As die gasheer se verstekpoort ’n ander router is, het daardie router die terugroete vir die VPN-voorvoegsel nodig. ’n Statiese roete op die RRAS-bediener help nie hier nie; die terugpad moet op die toestel bestaan wat die LAN-poort besit, so voeg dit by die roetetabel of by die dinamiese roeteringsproses, wat die terrein ook al gebruik.

Kontroleer ook die gasheer se vuurmuur en enige netwerktoegangsreëls teen die nuwe bronreeks. Reëls wat vir die ou kliëntreeks geskryf is, verwerp die nuwe een selfs al het die toewysing geslaag. Kliëntroetes na die LAN en DNS-resolusie is aparte vereistes, en albei kan misluk terwyl die tonnel gesond lyk. Toets elkeen op sy eie.

Bewys die nuwe poel op een toestel voordat jy die oue uit diens onttrek

Neem een magtiging wat jy beheer, verbind weer en lees die poeladres wat die kliënt ontvang het. Daardie enkele nommer skei toewysing van roetering. Oefen dan ’n genoemde toepassing, kyk na die terugverkeer en probeer ’n bestemming wat geweier moet bly. Drie waarnemings, drie verskillende faalwyses.

Naamresolusie verdien sy eie toets: toegang per IP kan werk terwyl die kliënt se DNS steeds na ’n resolveerder wys wat hy nie kan bereik nie. ’n DNS-bediener op die LAN is slegs bereikbaar as die kliënt ’n roete daarheen het en die bediener navrae van die nuwe reeks aanvaar. Albei is algemene gemiste punte wanneer die poel skuif.

Onttrek ou reekse en hul uitsonderings eers nadat aktiewe sessies en die instandhoudingsproses verreken is. ’n Verbinde kliënt met ’n nuwe adres bewys toewysing, nie die toegangsbeleid nie. Hou die ou reeks gedokumenteer totdat die laaste sessie wat dit gebruik het, verstryk het.

Kontroleer die resultaat met drie waarnemings

Aanvaarding vereis drie feite: die kliënt het ’n adres uit die nuwe poel, ’n LAN-gasheer kan dit bereik en ’n antwoord kry, en ’n geweierde bestemming word steeds geweier. Elkeen het sy eie kontrole, so ’n mislukking wys na toewysing, roetering of beleid. Voer hulle in daardie volgorde uit.

Vanaf die kliënt, bevestig die adres en die roete na een LAN-gasheer:

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

Vanaf die LAN-gasheer, bevestig die antwoordpad en die beleid in een gang. As ping misluk maar die toepassing werk, is die ontbrekende stuk waarskynlik ’n ICMP-reël eerder as die roete. As albei misluk, lees die roete op die gasheer voordat jy die VPN wysig. Teken die drie resultate in die veranderingsticket aan sodat die volgende persoon van bewyse af begin.