Clienții VPN din RRAS au nevoie de propriul pool IPv4 și de o cale de întoarcere

Clientul VPN se conectează și primește o adresă, dar gazda din LAN de care are nevoie încă nu îi poate răspunde. În Windows Routing and Remote Access, adresa internă a clienților VPN provine dintr-un pool configurat separat de adaptorul LAN al serverului, iar partea LAN are nevoie de o rută înapoi la acel pool. Două schimbări, nu una, și eșuează în moduri diferite. Parcurgeți-le în ordine pentru ca planul de adrese și calea de întoarcere să fie dovedite înainte ca intervalele vechi să fie retrase.

Rezervați intervalul înainte de a deschide consola

Alegeți un prefix care nu se suprapune cu LAN-ul, cu alte intervale VPN sau cu orice este rutat către site. Un /24 este o dimensiune comodă pentru un test, iar prima parte utilizabilă poate fi dată clienților în timp ce restul rămâne liber pentru creștere. Notați-l cu scopul și proprietarul înainte de a-l tasta într-o consolă. Lăsați spațiu la ambele capete ale blocului pentru ca o divizare ulterioară să nu impună renumerotare.

Un plan de adrese care trăiește doar într-o consolă este la o reconstrucție distanță de o coliziune. Tinde și să crească: cineva adaugă mai târziu un al doilea interval și nimeni nu îl verifică pe primul. Țineți planul lângă documentația serverului, nu într-un fir de chat.

Adaptorul LAN al serverului nu definește acest pool. Schimbarea ascultătorului public sau adăugarea unui adaptor la LAN face cu totul altceva. De aceea clienții se pot conecta și totuși primi o adresă din locul greșit. Poolul trăiește în proprietățile IPv4 ale serverului, nu în lista de adaptoare.

Schimbarea metodei nu este adăugarea unui interval

RRAS are o metodă de atribuire și un set de intervale. Trecerea de la DHCP la un pool static este o schimbare de metodă. Adăugarea unui alt bloc când poolul static este deja activ este o schimbare de interval.

Previzualizați ambele operații înainte de a executa vreuna, și citiți care corespunde stării actuale a serverului:

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

Al doilea cmdlet eșuează sau produce un pool inutilizabil dacă serverul este încă pe atribuire DHCP. Primul înlocuiește metoda în loc să extindă un pool existent. Niciuna dintre previzualizări nu aplică nimic, așa că rulați-o pe cea care corespunde, apoi confirmați poolul rezultat în consolă. Dacă nu sunteți sigur în ce stare este serverul, citiți metoda de atribuire în pagina de proprietăți IPv4 și listați intervalele configurate:

Get-VpnIPAddressRange

Metoda DHCP cu o listă de intervale goală înseamnă că se aplică prima previzualizare. Un pool static de adrese cu un interval existent înseamnă că se aplică a doua.

Luați în calcul repornirea serviciului pe care setarea o poate cere, și nu presupuneți că clienții conectați sunt renumerotați imediat. Un client care își păstrează adresa veche până se reconectează se comportă normal. Planificați schimbarea pentru o fereastră în care reconectarea este acceptabilă.

LAN-ul are nevoie de o rută de întoarcere

Să presupunem că LAN-ul este 10.60.0.0/24 și serverul RRAS este 10.60.0.10 în el. O gazdă din acel LAN care răspunde unui client din 10.250.50.0/24 are nevoie de o cale către pool prin serverul RRAS. Fără acea cale cererea ajunge și răspunsul moare.

Dacă poarta implicită a gazdei este un alt router, acel router are nevoie de ruta de întoarcere pentru prefixul VPN. O rută statică pe serverul RRAS nu ajută aici; calea de întoarcere trebuie să existe pe dispozitivul care deține poarta LAN, așa că adăugați-o în tabela de rutare sau în procesul de rutare dinamică, după cum folosește site-ul.

Verificați și paravanul gazdei și orice reguli de acces la rețea față de noul interval sursă. Regulile scrise pentru intervalul vechi de clienți îl resping pe cel nou chiar dacă atribuirea a reușit. Rutele clientului către LAN și rezolvarea DNS sunt cerințe separate, și ambele pot eșua în timp ce tunelul pare sănătos. Testați fiecare separat.

Dovediți noul pool pe un singur dispozitiv înainte de a-l retrage pe cel vechi

Luați o autorizare pe care o controlați, reconectați-vă și citiți adresa de pool primită de client. Acel singur număr separă atribuirea de rutare. Apoi exersați o aplicație numită, urmăriți traficul de întoarcere și încercați o destinație care trebuie să rămână refuzată. Trei observații, trei moduri diferite de eșec.

Rezolvarea numelor merită propriul test: accesul prin IP poate funcționa în timp ce DNS-ul clientului indică încă un resolver pe care nu îl poate atinge. Un server DNS din LAN este accesibil doar dacă clientul are o rută către el și serverul acceptă interogări din noul interval. Ambele sunt omisiuni frecvente când poolul se mută.

Retrageți intervalele vechi și excepțiile lor doar după ce ați luat în calcul sesiunile active și procesul de mentenanță. Un client conectat cu o adresă nouă dovedește atribuirea, nu politica de acces. Țineți intervalul vechi documentat până când ultima sesiune care l-a folosit a expirat.

Verificați rezultatul cu trei observații

Acceptarea cere trei fapte: clientul are o adresă din noul pool, o gazdă din LAN poate ajunge la el și primi un răspuns, iar o destinație refuzată rămâne refuzată. Fiecare are propria verificare, așa că un eșec indică atribuirea, rutarea sau politica. Rulați-le în acea ordine.

De la client, confirmați adresa și ruta către o gazdă din LAN:

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

De la gazda din LAN, confirmați calea de răspuns și politica într-o singură trecere. Dacă ping eșuează dar aplicația funcționează, piesa lipsă este probabil o regulă ICMP și nu ruta. Dacă ambele eșuează, citiți ruta pe gazdă înainte de a edita VPN-ul. Notați cele trei rezultate în tichetul de schimbare pentru ca următoarea persoană să pornească de la dovezi.