RRAS VPN-klienter trenger sin egen IPv4-pool og en vei tilbake

VPN-klienten kobler til og får en adresse, men LAN-verten den trenger kan fortsatt ikke svare den. I Windows Routing and Remote Access kommer den indre adressen til VPN-klienter fra en pool som konfigureres atskilt fra serverens LAN-adapter, og LAN-siden trenger en rute tilbake til den poolen. To endringer, ikke én, og de feiler på ulike måter. Gå gjennom dem i rekkefølge slik at adresseplanen og returveien er bevist før gamle områder tas ut av bruk.

Reserver området før du åpner konsollen

Velg et prefiks som ikke overlapper LAN, andre VPN-områder eller noe som rutes inn til nettstedet. Et /24 er en praktisk størrelse for en test, og den første brukbare delen kan gis til klienter mens resten står fritt til vekst. Skriv det ned med formål og eier før du taster det inn i en konsoll. La det være plass i begge ender av blokken slik at en senere deling ikke tvinger frem omnummerering.

En adresseplan som bare lever i en konsoll er én gjenoppbygging unna en kollisjon. Den har også en tendens til å vokse: noen legger til et andre område senere, og ingen sjekker det første. Oppbevar planen ved siden av serverdokumentasjonen, ikke i en chat-tråd.

Serverens LAN-adapter definerer ikke denne poolen. Å endre den offentlige lytteren eller legge til en adapter på LAN gjør noe helt annet. Derfor kan klienter koble til og likevel få en adresse fra feil sted. Poolen lever i serverens IPv4-egenskaper, ikke i adapterlisten.

Å bytte metode er ikke å legge til et område

RRAS har en tildelingsmetode og et sett med områder. Å gå fra DHCP til en statisk pool er en metodeendring. Å legge til en ny blokk mens den statiske poolen allerede er aktiv er en områdeendring.

Forhåndsvis begge operasjonene før du kjører noen av dem, og les hvilken som passer med serverens nåværende tilstand:

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

Den andre cmdleten feiler eller gir en ubrukelig pool hvis serveren fortsatt er på DHCP-tildeling. Den første erstatter metoden i stedet for å utvide en eksisterende pool. Ingen av forhåndsvisningene bruker noe, så kjør den som passer, og bekreft deretter den resulterende poolen i konsollen. Hvis du er usikker på hvilken tilstand serveren er i, kan du lese tildelingsmetoden på siden for IPv4-egenskaper og liste opp de konfigurerte områdene:

Get-VpnIPAddressRange

Metoden DHCP med en tom områdeliste betyr at den første forhåndsvisningen gjelder. En statisk adressepool med et eksisterende område betyr at den andre gjelder.

Regn med tjenestestarten innstillingen kan kreve, og ikke anta at tilkoblede klienter omnummereres med en gang. En klient som beholder sin gamle adresse til den kobler til på nytt, oppfører seg normalt. Planlegg endringen for et vindu der en ny tilkobling er akseptabel.

LAN-et trenger en rute tilbake

Anta at LAN-et er 10.60.0.0/24 og at RRAS-serveren er 10.60.0.10 på det. En vert på det LAN-et som svarer en klient i 10.250.50.0/24, trenger en vei til poolen gjennom RRAS-serveren. Uten den veien kommer forespørselen frem, og svaret dør.

Hvis vertens standard gateway er en annen ruter, trenger den ruteren returruten for VPN-prefikset. En statisk rute på RRAS-serveren hjelper ikke her; returveien må finnes på enheten som eier LAN-gatewayen, så legg den til i rutetabellen eller i den dynamiske ruteprosessen, avhengig av hva nettstedet bruker.

Sjekk også vertens brannmur og eventuelle regler for nettverkstilgang mot det nye kildeområdet. Regler skrevet for det gamle klientområdet avviser det nye selv om tildelingen lyktes. Klientruter mot LAN og DNS-oppslag er separate krav, og begge kan feile mens tunnelen ser sunn ut. Test hver for seg.

Bevis den nye poolen på én enhet før du tar den gamle ut av bruk

Ta én autorisasjon du kontrollerer, koble til på nytt og les pooladressen klienten fikk. Det ene tallet skiller tildeling fra ruting. Prøv deretter et navngitt program, følg med på returtrafikken og test en destinasjon som skal forbli avvist. Tre observasjoner, tre ulike feilmoduser.

Navneoppslag fortjener sin egen test: tilgang via IP kan virke mens klientens DNS fortsatt peker på en resolver den ikke når. En DNS-server på LAN-et er bare tilgjengelig hvis klienten har en rute dit og serveren godtar spørringer fra det nye området. Begge er vanlige mangler når poolen flyttes.

Ta gamle områder og unntakene deres ut av bruk først etter å ha tatt høyde for aktive økter og vedlikeholdsprosessen. En tilkoblet klient med ny adresse beviser tildelingen, ikke tilgangspolicyen. Hold det gamle området dokumentert til den siste økten som brukte det, er utløpt.

Sjekk resultatet med tre observasjoner

Godkjenning krever tre fakta: klienten har en adresse fra den nye poolen, en LAN-vert kan nå den og få svar, og en avvist destinasjon er fortsatt avvist. Hver har sin egen sjekk, så en feil peker på tildeling, ruting eller policy. Kjør dem i den rekkefølgen.

Fra klienten, bekreft adressen og ruten til én LAN-vert:

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

Fra LAN-verten, bekreft returveien og policyen i én omgang. Hvis ping feiler men programmet virker, er den manglende biten sannsynligvis en ICMP-regel og ikke ruten. Hvis begge feiler, les ruten på verten før du redigerer VPN-et. Noter de tre resultatene i endringssaken slik at neste person starter med bevis.