RRAS VPN-klienter behöver sin egen IPv4-pool och en väg tillbaka

VPN-klienten ansluter och får en adress, men LAN-värden den behöver kan fortfarande inte svara den. I Windows Routing and Remote Access kommer VPN-klienternas inre adress från en pool som konfigureras separat från serverns LAN-adapter, och LAN-sidan behöver en väg tillbaka till den poolen. Två ändringar, inte en, och de misslyckas på olika sätt. Arbeta igenom dem i ordning så att adressplanen och returvägen är bevisade innan gamla intervall tas ur bruk.

Reservera intervallet innan du öppnar konsolen

Välj ett prefix som inte överlappar LAN, andra VPN-intervall eller något som routas in till platsen. Ett /24 är en praktisk storlek för ett test, och den första användbara delen kan ges till klienter medan resten förblir fritt för tillväxt. Skriv ned det med syfte och ägare innan du skriver in det i en konsol. Lämna plats i båda ändar av blocket så att en senare delning inte tvingar fram omnumrering.

En adressplan som bara lever i en konsol är en återuppbyggnad från en kollision. Den tenderar också att växa: någon lägger till ett andra intervall senare och ingen kontrollerar det första. Förvara planen bredvid serverdokumentationen, inte i en chattråd.

Serverns LAN-adapter definierar inte den här poolen. Att ändra den offentliga lyssnaren eller lägga till en adapter på LAN gör något helt annat. Därför kan klienter ansluta och ändå få en adress från fel ställe. Poolen lever i serverns IPv4-egenskaper, inte i adapterlistan.

Att byta metod är inte att lägga till ett intervall

RRAS har en tilldelningsmetod och en uppsättning intervall. Att gå från DHCP till en statisk pool är en metodändring. Att lägga till ett block till medan den statiska poolen redan är aktiv är en intervalländring.

Förhandsgranska båda åtgärderna innan du kör någon av dem, och läs vilken som passar serverns nuvarande tillstånd:

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 andra cmdleten misslyckas eller ger en oanvändbar pool om servern fortfarande är på DHCP-tilldelning. Den första ersätter metoden i stället för att utöka en befintlig pool. Ingen av förhandsgranskningarna tillämpar något, så kör den som passar och bekräfta sedan den resulterande poolen i konsolen. Om du är osäker på vilket tillstånd servern är i, läs tilldelningsmetoden på sidan för IPv4-egenskaper och lista de konfigurerade intervallen:

Get-VpnIPAddressRange

Metoden DHCP med en tom intervallista betyder att den första förhandsgranskningen gäller. En statisk adresspool med ett befintligt intervall betyder att den andra gäller.

Räkna med den tjänstomstart som inställningen kan kräva, och anta inte att anslutna klienter numreras om direkt. En klient som behåller sin gamla adress tills den återansluter beter sig normalt. Planera ändringen för ett fönster där en återanslutning är acceptabel.

LAN behöver en väg tillbaka

Anta att LAN är 10.60.0.0/24 och att RRAS-servern är 10.60.0.10 på det. En värd på det LAN som svarar en klient i 10.250.50.0/24 behöver en väg till poolen via RRAS-servern. Utan den vägen kommer begäran fram och svaret dör.

Om värdens standardgateway är en annan router behöver den routern returvägen för VPN-prefixet. En statisk väg på RRAS-servern hjälper inte här; returvägen måste finnas på den enhet som äger LAN-gatewayen, så lägg till den i routingtabellen eller i den dynamiska routingprocessen, beroende på vad platsen använder.

Kontrollera också värdens brandvägg och eventuella regler för nätverksåtkomst mot det nya källintervallet. Regler skrivna för det gamla klientintervallet avvisar det nya även om tilldelningen lyckades. Klientvägar mot LAN och DNS-uppslag är separata krav, och båda kan misslyckas medan tunneln ser frisk ut. Testa varje för sig.

Bevisa den nya poolen på en enhet innan du tar den gamla ur bruk

Ta en auktorisering som du kontrollerar, återanslut och läs pooladressen som klienten fick. Den enda siffran skiljer tilldelning från routing. Öva sedan en namngiven applikation, följ returtrafiken och prova en destination som ska förbli nekad. Tre observationer, tre olika feltillstånd.

Namnuppslag förtjänar sitt eget test: åtkomst via IP kan fungera medan klientens DNS fortfarande pekar på en resolver den inte når. En DNS-server på LAN är bara nåbar om klienten har en väg dit och servern accepterar frågor från det nya intervallet. Båda är vanliga missar när poolen flyttas.

Ta gamla intervall och deras undantag ur bruk först efter att ha vägt in aktiva sessioner och underhållsprocessen. En ansluten klient med ny adress bevisar tilldelningen, inte åtkomstpolicyn. Håll det gamla intervallet dokumenterat tills den sista session som använde det har gått ut.

Kontrollera resultatet med tre observationer

Godkännande kräver tre fakta: klienten har en adress från den nya poolen, en LAN-värd kan nå den och få svar, och en nekad destination är fortfarande nekad. Varje har sin egen kontroll, så ett fel pekar på tilldelning, routing eller policy. Kör dem i den ordningen.

Från klienten, bekräfta adressen och vägen till en LAN-värd:

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

Från LAN-värden, bekräfta returvägen och policyn i en enda omgång. Om ping misslyckas men applikationen fungerar är den saknade biten sannolikt en ICMP-regel och inte vägen. Om båda misslyckas, läs vägen på värden innan du redigerar VPN:et. Anteckna de tre resultaten i ändringsärendet så att nästa person börjar med bevis.