RRASin VPN-asiakkaat tarvitsevat oman IPv4-altaan ja paluureitin

VPN-asiakas muodostaa yhteyden ja saa osoitteen, mutta isäntä LAN-verkossa, jota se tarvitsee, ei silti voi vastata sille. Windows Routing and Remote Accessissa VPN-asiakkaiden sisäinen osoite tulee altaasta, joka määritetään erikseen palvelimen LAN-sovittimesta, ja LAN-puoli tarvitsee paluureitin tuohon altaaseen. Kaksi muutosta, ei yksi, ja ne epäonnistuvat eri tavoin. Käy ne läpi järjestyksessä, jotta osoitesuunnitelma ja paluureitti on todistettu ennen kuin vanhat alueet poistetaan käytöstä.

Varaa alue ennen konsolin avaamista

Valitse etuliite, joka ei ole päällekkäinen LAN-verkon, muiden VPN-alueiden tai sivustolle reititetyn kanssa. /24 on kätevä koko testille, ja ensimmäinen käyttökelpoinen osa voidaan antaa asiakkaille, kun loput jää vapaaksi kasvulle. Kirjoita se muistiin käyttötarkoituksen ja omistajan kanssa ennen kuin kirjoitat sen konsoliin. Jätä tilaa lohkon molempiin päihin, jotta myöhempi jako ei pakota uudelleennumerointiin.

Osoitesuunnitelma, joka elää vain konsolissa, on yhden uudelleenrakennuksen päässä törmäyksestä. Se myös kasvaa helposti: joku lisää myöhemmin toisen alueen, eikä kukaan tarkista ensimmäistä. Pidä suunnitelma palvelimen dokumentaation vieressä, ei chat-ketjussa.

Palvelimen LAN-sovitin ei määritä tätä allasta. Julkisen kuuntelijan muuttaminen tai sovittimen lisääminen LAN-verkkoon tekee jotain aivan muuta. Siksi asiakkaat voivat yhdistää ja saada silti osoitteen väärästä paikasta. Allas elää palvelimen IPv4-ominaisuuksissa, ei sovitinluettelossa.

Menetelmän vaihtaminen ei ole alueen lisäämistä

RRASissa on osoitusmenetelmä ja joukko alueita. Siirtyminen DHCP:stä staattiseen altaaseen on menetelmän muutos. Toisen lohkon lisääminen, kun staattinen allas on jo aktiivinen, on alueen muutos.

Esikatsele molemmat toiminnot ennen kumman tahansa suorittamista ja lue, kumpi vastaa palvelimen nykyistä tilaa:

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

Toinen cmdlet epäonnistuu tai tuottaa käyttökelvottoman altaan, jos palvelin on vielä DHCP-osoituksessa. Ensimmäinen korvaa menetelmän sen sijaan, että laajentaisi olemassa olevaa allasta. Kumpikaan esikatselu ei ota mitään käyttöön, joten suorita sopiva ja vahvista sitten syntyvä allas konsolissa. Jos et ole varma palvelimen tilasta, lue osoitusmenetelmä IPv4-ominaisuuksien sivulta ja luettele määritetyt alueet:

Get-VpnIPAddressRange

Menetelmä DHCP ja tyhjä alueiden luettelo tarkoittaa, että ensimmäinen esikatselu pätee. Staattinen osoiteallas ja olemassa oleva alue tarkoittaa, että toinen pätee.

Ota huomioon palvelun uudelleenkäynnistys, jonka asetus voi vaatia, äläkä oleta, että yhdistetyt asiakkaat numeroidaan heti uudelleen. Asiakas, joka pitää vanhan osoitteensa kunnes yhdistää uudelleen, käyttäytyy normaalisti. Suunnittele muutos ikkunaan, jossa uudelleenyhdistäminen on hyväksyttävää.

LAN tarvitsee paluureitin

Oletetaan, että LAN on 10.60.0.0/24 ja RRAS-palvelin on siinä 10.60.0.10. Isäntä siinä LAN-verkossa, joka vastaa asiakkaalle osoitteessa 10.250.50.0/24, tarvitsee reitin altaaseen RRAS-palvelimen kautta. Ilman tätä reittiä pyyntö saapuu ja vastaus kuolee.

Jos isännän oletusyhdyskäytävä on toinen reititin, se reititin tarvitsee paluureitin VPN-etuliitteelle. Staattinen reitti RRAS-palvelimella ei auta tässä; paluureitin on oltava laitteessa, joka omistaa LAN-yhdyskäytävän, joten lisää se reititystauluun tai dynaamisen reitityksen prosessiin sen mukaan, mitä sivusto käyttää.

Tarkista myös isännän palomuuri ja kaikki verkon käyttösäännöt uutta lähdealuetta vastaan. Vanhalle asiakasalueelle kirjoitetut säännöt hylkäävät uuden, vaikka osoitus onnistui. Asiakkaan reitit LAN-verkkoon ja DNS-selvitys ovat erillisiä vaatimuksia, ja molemmat voivat epäonnistua, kun taas tunneli näyttää terveeltä. Testaa kumpaakin erikseen.

Todista uusi allas yhdellä laitteella ennen vanhan poistamista käytöstä

Ota yksi valtuutus, jota hallitset, yhdistä uudelleen ja lue altaan osoite, jonka asiakas sai. Se yksi luku erottaa osoituksen reitityksestä. Harjoittele sitten nimettyä sovellusta, seuraa paluuliikennettä ja kokeile kohdetta, jonka pitäisi pysyä estettynä. Kolme havaintoa, kolme eri vikatilaa.

Nimiselvitys ansaitsee oman testinsä: IP-osoitteella käyttäminen voi toimia, vaikka asiakkaan DNS osoittaa yhä ratkaisijaan, johon se ei pääse. LAN-verkon DNS-palvelin on tavoitettavissa vain, jos asiakkaalla on reitti siihen ja palvelin hyväksyy kyselyt uudesta alueesta. Molemmat ovat yleisiä puutteita, kun allas siirtyy.

Poista vanhat alueet ja niiden poikkeukset käytöstä vasta, kun aktiiviset istunnot ja ylläpitoprosessi on otettu huomioon. Yhdistetty asiakas, jolla on uusi osoite, todistaa osoituksen, ei käyttöoikeuskäytäntöä. Pidä vanha alue dokumentoituna, kunnes viimeinen sitä käyttänyt istunto on vanhentunut.

Tarkista tulos kolmella havainnolla

Hyväksyntä vaatii kolme tosiasiaa: asiakkaalla on osoite uudesta altaasta, LAN-isäntä pääsee siihen ja saa vastauksen, ja estetty kohde pysyy estettynä. Jokaisella on oma tarkistuksensa, joten vika osoittaa osoitukseen, reititykseen tai käytäntöön. Suorita ne tässä järjestyksessä.

Vahvista asiakkaan puolelta osoite ja reitti yhteen LAN-isäntään:

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

Vahvista LAN-isännän puolelta paluureitti ja käytäntö yhdellä kertaa. Jos ping epäonnistuu mutta sovellus toimii, puuttuva pala on todennäköisesti ICMP-sääntö eikä reitti. Jos molemmat epäonnistuvat, lue reitti isännällä ennen VPN:n muokkaamista. Kirjaa kolme tulosta muutospyyntöön, jotta seuraava aloittaa todisteista.