VPN-klienten opretter forbindelse og får en adresse, men den LAN-vært, den har brug for, kan stadig ikke svare den. I Windows Routing and Remote Access kommer den indre adresse til VPN-klienter fra en pulje, der konfigureres separat fra serverens LAN-adapter, og LAN-siden har brug for en rute tilbage til den pulje. To ændringer, ikke én, og de fejler på forskellige måder. Gå gennem dem i rækkefølge, så adresseplanen og returvejen er bevist, før gamle intervaller udfases.

Reservér intervallet, før du åbner konsollen

Vælg et præfiks, der ikke overlapper LAN, andre VPN-intervaller eller noget, der routes ind i lokaliteten. Et /24 er en bekvem størrelse til en test, og den første brugbare del kan gives til klienter, mens resten forbliver fri til vækst. Skriv det ned med formål og ejer, før du taster det ind i en konsol. Lad der være plads i begge ender af blokken, så en senere opdeling ikke tvinger en omnummerering.

En adresseplan, der kun lever i en konsol, er én genopbygning fra en kollision. Den har også tendens til at vokse: nogen tilføjer et andet interval senere, og ingen tjekker det første. Opbevar planen ved siden af serverdokumentationen, ikke i en chat-tråd.

Serverens LAN-adapter definerer ikke denne pulje. At ændre den offentlige lytter eller tilføje en adapter til LAN gør noget helt andet. Derfor kan klienter oprette forbindelse og stadig få en adresse fra det forkerte sted. Puljen lever i serverens IPv4-egenskaber, ikke på adapterlisten.

At skifte metode er ikke at tilføje et interval

RRAS har en tildelingsmetode og et sæt intervaller. At gå fra DHCP til en statisk pulje er en metodeændring. At tilføje endnu en blok, mens den statiske pulje allerede er aktiv, er en intervalændring.

Forhåndsvis begge handlinger, før du kører nogen af dem, og læs, hvilken der passer til serverens aktuelle 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 anden cmdlet fejler eller giver en ubrugelig pulje, hvis serveren stadig er på DHCP-tildeling. Den første erstatter metoden i stedet for at udvide en eksisterende pulje. Ingen af forhåndsvisningerne anvender noget, så kør den, der passer, og bekræft derefter den resulterende pulje i konsollen. Hvis du er usikker på, hvilken tilstand serveren er i, skal du læse tildelingsmetoden på egenskapssiden for IPv4 og liste de konfigurerede intervaller:

Get-VpnIPAddressRange

Metoden DHCP med en tom intervalliste betyder, at den første forhåndsvisning gælder. Statisk adressepulje med et eksisterende interval betyder, at den anden gælder.

Regn med den servicegenstart, indstillingen kan kræve, og antag ikke, at tilsluttede klienter omnummereres med det samme. En klient, der beholder sin gamle adresse, indtil den genopretter forbindelse, opfører sig normalt. Planlæg ændringen i et vindue, hvor en genoprettelse af forbindelsen er acceptabel.

LAN'et har brug for en rute tilbage

Antag, at LAN'et er 10.60.0.0/24, og at RRAS-serveren er 10.60.0.10 på det. En vært på det LAN, der svarer en klient i 10.250.50.0/24, har brug for en vej til puljen gennem RRAS-serveren. Uden den vej ankommer anmodningen, og svaret dør.

Hvis værtens standardgateway er en anden router, har den router brug for returruten til VPN-præfikset. En statisk rute på RRAS-serveren hjælper ikke her; returvejen skal findes på den enhed, der ejer LAN-gatewayen, så tilføj den til routingtabellen eller til den dynamiske routingproces, alt efter hvad lokaliteten bruger.

Kontrollér også værtens firewall og eventuelle netværksadgangsregler mod det nye kildeinterval. Regler skrevet til det gamle klientinterval afviser det nye, selv om tildelingen lykkedes. Klientruter mod LAN og DNS-opløsning er separate krav, og begge kan fejle, mens tunnelen ser sund ud. Test hver for sig.

Bevis den nye pulje på én enhed, før du udfaser den gamle

Tag én autorisation, du kontrollerer, genopret forbindelsen, og læs den puljeadresse, klienten fik. Det ene tal adskiller tildeling fra routing. Afprøv derefter et navngivet program, hold øje med returtrafikken, og prøv en destination, der skal blive afvist. Tre observationer, tre forskellige fejltilstande.

Navneopløsning fortjener sin egen test: adgang via IP kan virke, mens klientens DNS stadig peger på en resolver, den ikke kan nå. En DNS-server på LAN'et er kun tilgængelig, hvis klienten har en rute til den, og serveren accepterer forespørgsler fra det nye interval. Begge er almindelige mangler, når puljen flyttes.

Udfas gamle intervaller og deres undtagelser først efter at have taget højde for aktive sessioner og vedligeholdelsesprocessen. En tilsluttet klient med en ny adresse beviser tildeling, ikke adgangspolitikken. Hold det gamle interval dokumenteret, indtil den sidste session, der brugte det, er udløbet.

Kontrollér resultatet med tre observationer

Accept kræver tre fakta: klienten har en adresse fra den nye pulje, en LAN-vært kan nå den og få et svar, og en afvist destination er stadig afvist. Hver har sin egen kontrol, så en fejl peger på tildeling, routing eller politik. Kør dem i den rækkefølge.

Fra klienten bekræfter du adressen og ruten til én LAN-vært:

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

Fra LAN-værten bekræfter du returvejen og politikken i én omgang. Hvis ping fejler, men programmet virker, er den manglende brik sandsynligvis en ICMP-regel og ikke ruten. Hvis begge fejler, skal du læse ruten på værten, før du redigerer VPN. Notér de tre resultater i ændringsbilletten, så den næste person starter med beviser.

Relaterede artikler