NAT al servidor VPN o al router? Totes dues opcions poden funcionar

Marcar una connexió com a ruta per defecte en un portàtil és el pas que tothom recorda, i és el que no canvia res a la passarel·la. El client ara envia les peticions d’Internet al túnel; si surten de l’edifici depèn del reenviament, d’un punt de traducció i d’un camí de tornada que arribi a l’adreça privada del client. Dues disposicions poden proporcionar les tres coses, posen la feina en llocs diferents, i totes dues fallen de la mateixa manera silenciosa quan ningú s’ocupa de la direcció de la resposta. Triar entre elles és una qüestió de qui ha de veure el pool de clients.

El mite: una ruta de client construeix la sortida

El tunneling forçat és una política del costat del client: decideix que el trànsit vagi a l’adaptador VPN en lloc del físic. La documentació d’encaminament VPN de Microsoft descriu aquest comportament de separació i de força, i és una afirmació sobre la taula d’encaminament del client, no sobre les regles de reenviament del servidor. Des del punt de vista del client, el túnel és on viu Internet; des del punt de vista de la passarel·la, un paquet ha arribat d’una adreça que ningú aigües amunt no ha sentit mai. Cap dels dos costats està mal configurat per si sol, i per això el fallo sembla un servidor espatllat per a la persona que hi ha al portàtil.

Aquest desajust és tot el problema que resol la resta de l’article. Alguna cosa ha de fer que l’adreça privada del client sigui retornable, i l’elecció és on.

Dibuixeu primer el camí de tornada

Escriviu el camí amb adreces reals abans de tocar cap paràmetre, i marqueu-hi els dos punts de traducció candidats. Aquest laboratori fa servir un pool VPN de 10.70.0.0/24 amb un client a 10.70.0.37, una adreça LAN del servidor de 172.16.40.10, un router a 172.16.40.1 i una sortida pública de 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

El servidor que ja navega per Internet només demostra el seu propi camí. Un paquet reenviat en nom d’un client és una decisió diferent, presa per la política de reenviament a la mateixa màquina, i és la que normalment falta. Marcar els tres punts de decisió al diagrama manté la conversa sobre un d’ells alhora.

Opció A: traduir al servidor VPN

Aquí el servidor tradueix l’origen del client a la seva pròpia adreça LAN abans de lliurar el paquet al router, i el router aplica la seva traducció habitual a la sortida. A la resposta, el mapatge del router restaura l’adreça del servidor i el mapatge del servidor restaura l’adreça del client. Dues traduccions amb estat en sèrie són normals i viables, sempre que totes dues quedin registrades; el router no necessita mai una ruta cap al pool, que és l’al·licient d’aquesta disposició.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Feu servir aquestes lectures per veure què té ja el servidor en lloc de suposar que hi ha un NAT. Una regla de masquerade de Linux copiada d’un blog no és una configuració de Windows, i un permís al tallafoc de l’amfitrió per al listener VPN no és la mateixa política que el permís per reenviar la petició d’un client més enllà. Confirmeu el paper de reenviament del servidor des de la seva pròpia superfície de gestió, i després mireu la traducció per separat, perquè les dues coses sovint s’habiliten des de parts diferents d’un desplegament.

Opció B: portar el pool al router

En la segona disposició el servidor reenvia l’adreça d’origen real del client, i el router la tradueix. Això manté el pool de clients visible a la vora, cosa que ajuda si el router és on viuen la política de trànsit, el registre o la inspecció. També vol dir que el router necessita una ruta de tornada per a 10.70.0.0/24 que apunti a 172.16.40.10, a més d’una política d’Internet que inclogui realment aquest prefix; una regla escrita per a la subxarxa LAN no s’estén silenciosament al pool.

Trieu aquesta opció quan el dispositiu de vora sigui el propietari previst de la política i pugui acceptar un altre prefix a les seves taules d’encaminament i traducció. Trieu la traducció al costat del servidor quan el pool hagi de quedar invisible aigües amunt i el router no l’administri el mateix equip. Cap de les dues opcions no s’infereix de cap casella del client, i cap no és més segura en general; posen la visibilitat i el manteniment en llocs diferents.

Feu explícits el DNS, l’IPv6 i l’acceptació

La traducció d’adreces no arregla la resolució de noms. El client pot fer servir un resolutor lliurat amb el perfil VPN, un resolutor privat per a espais de noms concrets, o un de públic aprovat, i un resolutor inabastable sota aquesta política continuarà fallant després que l’encaminament funcioni. Proveu un nom i una adreça per separat perquè els dos fallos no s’acabin fusionant en un sol informe.

L’IPv6 necessita el seu propi paràgraf al disseny. Una traducció IPv4 que funcioni no diu res sobre si els clients IPv6 tenen ruta, una font pública vàlida o una política que els bloqui quan el túnel cau. Deixar-ho sense dir vol dir que la meitat dels clients eviten la passarel·la en silenci mentre l’altra meitat funciona.

Per a l’acceptació, seguiu una petició de client permesa i la seva resposta per les dues fronteres, i anoteu quina adreça hauria de veure cada frontera en aquell moment. Aquest registre és el que converteix el següent canvi de pool en una edició de cinc minuts en lloc d’una discussió sobre qui posseeix la ruta de tornada que falta. Guardeu el registre amb el perfil del client en lloc d’en un tiquet, ja que el perfil és el que el proper enginyer trobarà primer.