RRAS VPN-klientar treng eigen IPv4-pool og ein veg tilbake

VPN-klienten koplar til og får ei adresse, men LAN-verten han treng, kan framleis ikkje svare han. I Windows Routing and Remote Access kjem den indre adressa til VPN-klientar frå ein pool som blir konfigurert skilt frå LAN-adapteren til tenaren, og LAN-sida treng ei rute tilbake til den poolen. To endringar, ikkje éi, og dei feilar på ulike måtar. Gå gjennom dei i rekkjefølgje slik at adresseplanen og returvegen er prova før gamle område blir tekne ut av bruk.

Reserver området før du opnar konsollen

Vel eit prefiks som ikkje overlappar LAN, andre VPN-område eller noko som blir ruta inn til nettstaden. Eit /24 er ei praktisk storleik for ein test, og den første brukbare delen kan givast til klientar medan resten står fritt til vekst. Skriv det ned med føremål og eigar før du tastar det inn i ein konsoll. Lat det vere plass i begge endar av blokka slik at ei seinare deling ikkje tvingar fram omnummerering.

Ein adresseplan som berre lever i ein konsoll er éin gjenoppbygging unna ein kollisjon. Han har også ein tendens til å vekse: nokon legg til eit andre område seinare, og ingen sjekkar det første. Oppbevar planen ved sida av tenardokumentasjonen, ikkje i ein chat-tråd.

LAN-adapteren til tenaren definerer ikkje denne poolen. Å endre den offentlege lyttaren eller leggje til ein adapter på LAN gjer noko heilt anna. Difor kan klientar kople til og likevel få ei adresse frå feil stad. Poolen lever i IPv4-eigenskapane til tenaren, ikkje i adapterlista.

Å byte metode er ikkje å leggje til eit område

RRAS har ein tildelingsmetode og eit sett med område. Å gå frå DHCP til ein statisk pool er ei metodeendring. Å leggje til ei ny blokk medan den statiske poolen allereie er aktiv, er ei områdeendring.

Sjå føre deg begge operasjonane før du køyrer nokon av dei, og les kva som passar med den noverande tilstanden til tenaren:

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 feilar eller gjev ein ubrukeleg pool viss tenaren framleis er på DHCP-tildeling. Den første erstattar metoden i staden for å utvide ein eksisterande pool. Ingen av førehandsvisingane brukar noko, så køyr den som passar, og stadfest deretter den resulterande poolen i konsollen. Viss du er usikker på kva tilstand tenaren er i, les du tildelingsmetoden på sida for IPv4-eigenskapar og listar opp dei konfigurerte områda:

Get-VpnIPAddressRange

Metoden DHCP med ei tom områdeliste betyr at den første førehandsvisinga gjeld. Ein statisk adressepool med eit eksisterande område betyr at den andre gjeld.

Rekn med tenestestarten innstillinga kan krevje, og ikkje gå ut frå at tilkopla klientar blir omnummererte med ein gong. Ein klient som held på den gamle adressa si til han koplar til på nytt, oppfører seg normalt. Planlegg endringa for eit vindauge der ein ny tilkopling er akseptabel.

LAN-et treng ei rute tilbake

Anta at LAN-et er 10.60.0.0/24 og at RRAS-tenaren er 10.60.0.10 på det. Ein vert på det LAN-et som svarar ein klient i 10.250.50.0/24, treng ein veg til poolen gjennom RRAS-tenaren. Utan den vegen kjem førespurnaden fram, og svaret døyr.

Viss standard gateway til verten er ein annan ruter, treng den ruteren returruta for VPN-prefikset. Ei statisk rute på RRAS-tenaren hjelper ikkje her; returvegen må finnast på eininga som eig LAN-gatewayen, så legg henne til i rutetabellen eller i den dynamiske ruteprosessen, avhengig av kva nettstaden brukar.

Sjekk også brannmuren til verten og eventuelle reglar for nettverkstilgang mot det nye kjeldeområdet. Reglar skrivne for det gamle klientområdet avviser det nye sjølv om tildelinga lukkast. Klientruter mot LAN og DNS-oppslag er separate krav, og begge kan feile medan tunnelen ser sunn ut. Test kvar for seg.

Prov den nye poolen på éi eining før du tek den gamle ut av bruk

Tak éin autorisasjon du kontrollerer, kople til på nytt og les pooladressa klienten fekk. Det eine talet skil tildeling frå ruting. Prøv deretter eit namngjeve program, følg med på returtrafikken og test ein destinasjon som skal halde fram med å vere avvist. Tre observasjonar, tre ulike feilmodusar.

Namneoppslag fortener sin eigen test: tilgang via IP kan verke medan DNS-en til klienten framleis peikar på ein resolver han ikkje når. Ein DNS-tenar på LAN-et er berre tilgjengeleg viss klienten har ei rute dit og tenaren godtek spørjingar frå det nye området. Begge er vanlege manglar når poolen blir flytta.

Tak gamle område og unntaka deira ut av bruk først etter å ha teke omsyn til aktive økter og vedlikehaldsprosessen. Ein tilkopla klient med ny adresse provar tildelinga, ikkje tilgangspolicyen. Hald det gamle området dokumentert til den siste økta som brukte det, er gått ut.

Sjekk resultatet med tre observasjonar

Godkjenning krev tre fakta: klienten har ei adresse frå den nye poolen, ein LAN-vert kan nå han og få svar, og ein avvist destinasjon er framleis avvist. Kvar har sin eigen sjekk, så ein feil peikar på tildeling, ruting eller policy. Køyr dei i den rekkjefølgja.

Frå klienten, stadfest adressa og ruta til éin LAN-vert:

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

Frå LAN-verten, stadfest returvegen og policyen i ein omgang. Viss ping feilar men programmet verkar, er den manglande biten truleg ein ICMP-regel og ikkje ruta. Viss begge feilar, les ruta på verten før du redigerer VPN-et. Noter dei tre resultata i endringssaka slik at neste person startar med prov.