RRAS VPN-clients hebben hun eigen IPv4-pool en een weg terug nodig

De VPN-client maakt verbinding en krijgt een adres, maar de LAN-host die hij nodig heeft kan hem nog steeds niet antwoorden. In Windows Routing and Remote Access komt het interne adres van VPN-clients uit een pool die los van de LAN-adapter van de server wordt geconfigureerd, en de LAN-kant heeft een route terug naar die pool nodig. Twee wijzigingen, niet één, en ze falen op verschillende manieren. Werk ze op volgorde af zodat het adresplan en de terugweg bewezen zijn voordat oude bereiken buiten gebruik gaan.

Reserveer het bereik voordat u de console opent

Kies een prefix dat niet overlapt met de LAN, andere VPN-bereiken of iets dat naar de locatie wordt gerouteerd. Een /24 is een handige maat voor een test, en het eerste bruikbare deel kan aan clients worden gegeven terwijl de rest vrij blijft voor groei. Schrijf het met doel en eigenaar op voordat u het in een console typt. Laat aan beide uiteinden van het blok ruimte zodat een latere splitsing geen hernummering afdwingt.

Een adresplan dat alleen in een console leeft, is één herbouw verwijderd van een botsing. Het groeit ook gauw: iemand voegt later een tweede bereik toe en niemand controleert het eerste. Bewaar het plan naast de serverdocumentatie, niet in een chatthread.

De LAN-adapter van de server bepaalt deze pool niet. De publieke listener wijzigen of een adapter aan de LAN toevoegen doet iets heel anders. Daarom kunnen clients verbinden en toch een adres van de verkeerde plek krijgen. De pool leeft in de IPv4-eigenschappen van de server, niet in de adapterlijst.

De methode wijzigen is geen bereik toevoegen

RRAS heeft een toewijzingsmethode en een set bereiken. Van DHCP naar een statische pool gaan is een methodewijziging. Nog een blok toevoegen terwijl de statische pool al actief is, is een bereikwijziging.

Bekijk beide bewerkingen voordat u er een uitvoert, en lees welke bij de huidige toestand van de server past:

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

De tweede cmdlet mislukt of levert een onbruikbare pool op als de server nog op DHCP-toewijzing staat. De eerste vervangt de methode in plaats van een bestaande pool uit te breiden. Geen van beide voorbeelden past iets toe, dus voer de passende uit en bevestig daarna de resulterende pool in de console. Als u niet zeker weet in welke toestand de server verkeert, lees dan de toewijzingsmethode op de pagina met IPv4-eigenschappen en som de geconfigureerde bereiken op:

Get-VpnIPAddressRange

De methode DHCP met een lege bereikenlijst betekent dat de eerste voorbeeldweergave geldt. Een statische adrespool met een bestaand bereik betekent dat de tweede geldt.

Houd rekening met de servicestart die de instelling kan vereisen, en ga er niet van uit dat verbonden clients meteen opnieuw worden genummerd. Een client die zijn oude adres houdt tot hij opnieuw verbindt, gedraagt zich normaal. Plan de wijziging voor een venster waarin opnieuw verbinden acceptabel is.

De LAN heeft een route terug nodig

Stel dat de LAN 10.60.0.0/24 is en de RRAS-server 10.60.0.10 daarop. Een host op die LAN die een client in 10.250.50.0/24 antwoordt, heeft een pad naar de pool via de RRAS-server nodig. Zonder dat pad komt het verzoek aan en sterft het antwoord.

Als de standaardgateway van de host een andere router is, heeft die router de retourroute voor het VPN-prefix nodig. Een statische route op de RRAS-server helpt hier niet; de terugweg moet bestaan op het apparaat dat de LAN-gateway bezit, dus voeg hem toe aan de routingtabel of aan het dynamische routingproces, afhankelijk van wat de locatie gebruikt.

Controleer ook de firewall van de host en alle regels voor netwerktoegang tegen het nieuwe bronbereik. Regels die voor het oude clientbereik zijn geschreven, weigeren het nieuwe zelfs als de toewijzing is gelukt. Clientroutes naar de LAN en DNS-resolutie zijn aparte vereisten, en beide kunnen falen terwijl de tunnel gezond lijkt. Test ze elk apart.

Bewijs de nieuwe pool op één apparaat voordat u de oude buiten gebruik neemt

Neem één autorisatie die u beheert, verbind opnieuw en lees het pooladres dat de client kreeg. Dat ene nummer scheidt toewijzing van routing. Test daarna een benoemde toepassing, kijk naar het retourverkeer en probeer een bestemming die geweigerd moet blijven. Drie waarnemingen, drie verschillende faalwijzen.

Naamresolutie verdient een eigen test: toegang via IP kan werken terwijl de DNS van de client nog naar een resolver wijst die hij niet kan bereiken. Een DNS-server op de LAN is alleen bereikbaar als de client er een route naartoe heeft en de server query's uit het nieuwe bereik accepteert. Beide zijn veelvoorkomende missers wanneer de pool verhuist.

Neem oude bereiken en hun uitzonderingen pas buiten gebruik na actieve sessies en het onderhoudsproces te hebben meegewogen. Een verbonden client met een nieuw adres bewijst de toewijzing, niet het toegangsbeleid. Houd het oude bereik gedocumenteerd tot de laatste sessie die het gebruikte is verlopen.

Controleer het resultaat met drie waarnemingen

Acceptatie vereist drie feiten: de client heeft een adres uit de nieuwe pool, een LAN-host kan hem bereiken en een antwoord krijgen, en een geweigerde bestemming blijft geweigerd. Elk heeft zijn eigen controle, dus een fout wijst op toewijzing, routing of beleid. Voer ze in die volgorde uit.

Bevestig vanaf de client het adres en de route naar één LAN-host:

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

Bevestig vanaf de LAN-host de retourweg en het beleid in één keer. Als ping faalt maar de toepassing werkt, is het ontbrekende stuk waarschijnlijk een ICMP-regel en niet de route. Als beide falen, lees dan de route op de host voordat u de VPN bewerkt. Noteer de drie resultaten in de wijzigingsticket zodat de volgende persoon met bewijs begint.