El client VPN es connecta i rep una adreça, però l’equip de la LAN que necessita encara no pot respondre-li. A Windows Routing and Remote Access, l’adreça interna dels clients VPN prové d’una reserva configurada per separat de l’adaptador de LAN del servidor, i el costat de la LAN necessita una ruta de tornada cap a aquesta reserva. Dos canvis, no un, i fallen de maneres diferents. Feu-los en ordre perquè el pla d’adreces i el camí de tornada quedin demostrats abans de retirar els intervals antics.

Reserveu l’interval abans d’obrir la consola

Trieu un prefix que no se superposi amb la LAN, amb altres intervals VPN ni amb res que es dirigeixi al lloc. Una /24 és una mida convenient per a una prova, i la primera part utilitzable es pot lliurar als clients mentre la resta queda lliure per al creixement. Anoteu-lo amb el seu propòsit i propietari abans d’escriure’l en una consola. Deixeu espai als dos extrems del bloc perquè una divisió posterior no obligui a renumerar.

Un pla d’adreces que només viu en una consola és a una reconstrucció d’una col·lisió. També tendeix a créixer: algú afegeix un segon interval més endavant i ningú comprova el primer. Guardeu el pla al costat de la documentació del servidor, no en un fil de xat.

L’adaptador de LAN del servidor no defineix aquesta reserva. Canviar l’oient públic o afegir un adaptador a la LAN fa una cosa completament diferent. Per això els clients es poden connectar i tot i així rebre una adreça del lloc equivocat. La reserva viu a les propietats IPv4 del servidor, no a la llista d’adaptadors.

Canviar el mètode no és afegir un interval

RRAS té un mètode d’assignació i un conjunt d’intervals. Passar de DHCP a una reserva estàtica és un canvi de mètode. Afegir un altre bloc mentre la reserva estàtica ja és activa és un canvi d’interval.

Previsualitzeu les dues operacions abans d’executar-ne cap, i llegiu quina coincideix amb l’estat actual del servidor:

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

La segona cmdlet falla o produeix una reserva inutilitzable si el servidor encara està en assignació DHCP. La primera substitueix el mètode en lloc d’ampliar una reserva existent. Cap de les dues previsualitzacions aplica res, així que executeu la que coincideixi i després confirmeu la reserva resultant a la consola. Si no esteu segur de l’estat del servidor, llegiu el mètode d’assignació a la pàgina de propietats IPv4 i lliste els intervals configurats:

Get-VpnIPAddressRange

Un mètode DHCP amb una llista d’intervals buida significa que s’aplica la primera previsualització. Una reserva d’adreces estàtica amb un interval existent significa que s’aplica la segona.

Compteu amb el reinici del servei que el paràmetre pot requerir, i no assumiu que els clients connectats es renumerin immediatament. Un client que conserva la seva adreça antiga fins que es reconnecta es comporta normalment. Planifiqueu el canvi per a una finestra en què una reconnexió sigui acceptable.

La LAN necessita una ruta de tornada

Suposeu que la LAN és 10.60.0.0/24 i que el servidor RRAS és 10.60.0.10 en ella. Un equip d’aquesta LAN que respon a un client de 10.250.50.0/24 necessita un camí cap a la reserva a través del servidor RRAS. Sense aquest camí, la petició arriba i la resposta mor.

Si la passarel·la per defecte de l’equip és un altre encaminador, aquest encaminador necessita la ruta de tornada per al prefix VPN. Una ruta estàtica al servidor RRAS no ajuda aquí; el camí de tornada ha d’existir al dispositiu que posseeix la passarel·la de la LAN, així que afegiu-lo a la taula d’encaminament o al procés d’encaminament dinàmic, segons el que faci servir el lloc.

Comproveu també el tallafoc de l’equip i qualsevol regla d’accés a la xarxa contra el nou interval d’origen. Les regles escrites per a l’interval antic de clients rebutgen el nou encara que l’assignació hagi funcionat. Les rutes del client cap a la LAN i la resolució DNS són requisits separats, i tots dos poden fallar mentre el túnel sembla sa. Proveu cada un per separat.

Demostreu la reserva nova en un sol dispositiu abans de retirar la vella

Agafeu una autorització que controleu, reconnecteu-vos i llegiu l’adreça de reserva que ha rebut el client. Aquest sol número separa l’assignació de l’encaminament. Després exerciteu una aplicació concreta, observeu el trànsit de tornada i proveu una destinació que ha de continuar denegada. Tres observacions, tres maneres diferents de fallar.

La resolució de noms mereix la seva pròpia prova: l’accés per IP pot funcionar mentre el DNS del client encara apunta a un resolutor al qual no pot arribar. Un servidor DNS a la LAN només és accessible si el client té una ruta cap a ell i el servidor accepta consultes del nou interval. Tots dos són errors habituals quan es mou la reserva.

Retireu els intervals antics i les seves excepcions només després de comptar les sessions actives i el procés de manteniment. Un client connectat amb una adreça nova demostra l’assignació, no la política d’accés. Manteniu l’interval antic documentat fins que hagi caducat l’última sessió que el va utilitzar.

Comproveu el resultat amb tres observacions

L’acceptació necessita tres fets: el client té una adreça de la reserva nova, un equip de la LAN hi pot arribar i obtenir resposta, i una destinació denegada continua denegada. Cada un té la seva comprovació, així que un fracàs apunta a l’assignació, a l’encaminament o a la política. Executeu-les en aquest ordre.

Des del client, confirmeu l’adreça i la ruta cap a un equip de la LAN:

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

Des de l’equip de la LAN, confirmeu el camí de resposta i la política en una sola passada. Si ping falla però l’aplicació funciona, la peça que falta és probablement una regla ICMP i no la ruta. Si fallen tots dos, llegiu la ruta a l’equip abans d’editar la VPN. Anoteu els tres resultats al tiquet de canvi perquè la següent persona comenci amb proves.

Articles relacionats