RRAS VPN-klanten hawwe in eigen IPv4-pool en in paad werom nedich

De VPN-klant ferbynt en krijt in adres, mar de LAN-host dy’t er nedich hat kin him noch altyd net antwurdzje. Yn Windows Routing and Remote Access komt it binnenadres foar VPN-klanten út in pool dy’t apart fan de LAN-adapter fan ’e server konfigurearre wurdt, en de LAN-kant hat in rûte werom nei dy pool nedich. Twa feroarings, net ien, en se mislearje op ferskillende manieren. Wurkje se op folchoarder ôf, sadat it adresplan en it paad werom bewiisd binne foardat âlde berikken bûten gebrûk nommen wurde.

Reservearje it berik foardat jo de konsôle iepenje

Kies in foarheaksel dat net oerlaapet mei de LAN, oare VPN-berikken of wat dan ek dat nei de site rûte wurdt. In /24 is in handige grutte foar in test, en it earste brûkbere part kin oan klanten jûn wurde wylst de rest frij bliuwt foar groei. Skriuw it op mei syn doel en eigner foardat jo it yn in konsôle type. Lit romte oan beide einen fan it blok, sadat in lettere splitsing gjin fernijde nûmering twinge.

In adresplan dat allinnich yn in konsôle libbet is ien weropbou fan in botsing ôf. It hat ek de oanstriid om te groeien: immen foeget letter in twadde berik ta en nimmen kontrolearret it earste. Hâld it plan njonken de serverdokumintaasje, net yn in petearried.

De LAN-adapter fan ’e server definiearret dizze pool net. De publike listener feroarje of in adapter oan de LAN tafoegje docht hiel wat oars. Dêrom kinne klanten ferbine en dochs in adres fan ’e ferkearde plak krije. De pool libbet yn ’e IPv4-eigenskippen fan ’e server, net yn ’e adapterlist.

De metoade feroarje is gjin berik tafoegje

RRAS hat in tawizingsmetoade en in set berikken. Fan DHCP nei in statyske pool gean is in metoadeferoaring. In oar blok tafoegje wylst de statyske pool al aktyf is, is in berikferoaring.

Besjoch beide operaasjes foardat jo ien útfiere, en lês hokker by de hjoeddeiske steat fan ’e 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 twadde cmdlet mislearret of leveret in ûnbrûkbere pool as de server noch op DHCP-tawizing stiet. De earste ferfangt de metoade yn stee fan in besteande pool út te wreidzjen. Gjin fan beide foarbylden past wat ta, dus fiere jo dy út dy’t past en befêstigje dan de resultearjende pool yn ’e konsôle. As jo net wis binne yn hokker steat de server is, lês dan de tawizingsmetoade op ’e side mei IPv4-eigenskippen en list de konfigurearre berikken op:

Get-VpnIPAddressRange

In metoade DHCP mei in lege beriklist betsjut dat de earste foarbyld jildt. In statyske adrespool mei in besteand berik betsjut dat de twadde jildt.

Rekkenje mei de tsjinstwerstart dy’t de ynstelling freegje kin, en nim net oan dat ferbûne klanten daliks fernijde nûmere wurde. In klant dy’t syn âlde adres hâldt oant er wer ferbynt, docht him normaal. Plan de feroaring foar in finster wêryn’t in werferbining akseptabel is.

De LAN hat in rûte werom nedich

Stel dat de LAN 10.60.0.0/24 is en de RRAS-server 10.60.0.10 dêrop. In host op dy LAN dy’t antwurdet oan in klant yn 10.250.50.0/24 hat in paad nei de pool fia de RRAS-server nedich. Sûnder dat paad komt it fersyk oan en stjert it antwurd.

As de standertgateway fan ’e host in oare router is, hat dy router de weromrûte foar it VPN-foarheaksel nedich. In statyske rûte op ’e RRAS-server helpt hjir net; it paad werom moat bestean op it apparaat dat de LAN-gateway besit, dus foegje it ta oan ’e rûtingstabel of oan it dynamyske rûteproses, neffens wat de site brûkt.

Kontrolearje ek de firewall fan ’e host en alle regels foar netwurk tagong tsjin it nije boarneberik. Regels skreaun foar it âlde klantberik wegerje it nije, sels as de tawizing slagge is. Klantrûtes nei de LAN en DNS-oplossing binne aparte easken, en beide kinne mislearje wylst de tunnel sûn liket. Test elk apart.

Bewiis de nije pool op ien apparaat foardat jo de âlde bûten gebrûk nimme

Nim ien autorisaasje dy’t jo kontrolearje, ferbyn wer en lês it pooladres dat de klant krige. Dat iene nûmer skiedt tawizing fan rûting. Oefenje dan in neamd programma, sjoch it weromferkear en besykje in bestimming dy’t wegerjen bliuwe moat. Trije observaasjes, trije ferskillende falmanieren.

Namme-oplossing fertsjinnet syn eigen test: tagong fia IP kin wurkje wylst de DNS fan ’e klant noch nei in resolver wiist dy’t er net berikke kin. In DNS-server op ’e LAN is allinnich berikber as de klant in rûte dêrhinne hat en de server fragen út it nije berik akseptearret. Beide binne faak miste punten as de pool ferpleatst.

Nim âlde berikken en har útsûnderingen pas bûten gebrûk nei’t jo aktive sesjes en it ûnderhâldsproses meirekkene hawwe. In ferbûne klant mei in nij adres bewiist tawizing, net it tagongsbelied. Hâld it âlde berik dokumintearre oant de lêste sesje dy’t it brûkte ferrûn is.

Kontrolearje it resultaat mei trije observaasjes

Akseptaasje freget trije feiten: de klant hat in adres út ’e nije pool, in LAN-host kin him berikke en in antwurd krije, en in wegere bestimming is noch altyd wegere. Elk hat syn eigen kontrôle, dus in mislearring wiist op tawizing, rûting of belied. Fier se yn dy folchoarder út.

Fan ’e klant ôf, befêstigje it adres en de rûte nei ien LAN-host:

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

Fan ’e LAN-host ôf, befêstigje it antwurdpaad en it belied yn ien gong. As ping mislearret mar it programma wurket, is it ûntbrekkende stik wierskynlik in ICMP-regel en net de rûte. As beide mislearje, lês de rûte op ’e host foardat jo de VPN bewurkje. Skriuw de trije resultaten yn ’e feroarjingskaart, sadat de folgjende persoan fan bewiis útgiet.