La mateixa subxarxa als dos extrems: assigneu la LAN remota a un rang lliure
L'assignació d'adreces al costat del client pot presentar una LAN remota solapada sota un rang lliure, però només alguns clients l'apliquen i el camí de tornada ha d'existir igualment.
La casa i l'oficina fan servir totes dues 192.168.1.0/24, així que una petició a 192.168.1.1 té dues respostes possibles i el client tria una sense preguntar. Renumerar una xarxa d'oficina en funcionament poques vegades és popular, i les adreces del router sovint estan incrustades en impressores, càmeres i documentació. L'assignació d'adreces al costat del client pot presentar la xarxa remota sota un rang lliure en lloc d'això, i la part d'amfitrió pot romandre idèntica de manera que 192.168.1.20 aparegui com 10.203.41.20. La trampa és que només alguns clients ho implementen, i no fa res pel camí de tornada.
Dues visions del mateix amfitrió
L'assignació conserva la part d'amfitrió i només canvia la part de xarxa. Aleshores la mateixa màquina respon en dues adreces segons on sigueu. Escriure les dues columnes abans de configurar res evita una mala lectura posterior dels registres i de les regles del tallafoc.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
Els dispositius locals de casa conserven les seves adreces 192.168.1.x, i aquest és el punt de l'exercici. La impressora de la sala del costat continua sent accessible mentre l'oficina apareix sota un rang que no entra en conflicte.
L'ordre dels arguments és tot el truc
L'opció pren una direcció, una xarxa i una màscara, i un àlies: la primera xarxa és el que veu el client, l'àlies és el que veu el servidor. Per als recursos que viuen darrere de la passarel·la remota, la direcció és la forma de destinació. Invertir les dues xarxes perquè l'últim argument es diu àlies és l'error que produeix un túnel que es connecta i no assigna res.
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"La ruta és el que envia els paquets del client per al nou rang cap al túnel; la traducció reescriu la destinació durant el pas. Una resposta de 192.168.1.20 es reescriu de tornada a 10.203.41.20 perquè el sòcol del client es mantingui coherent. Un sol amfitrió funciona igual amb una màscara de longitud completa, sempre que la ruta i l'assignació descriguin la mateixa adreça.
Això és una assignació d'adreces, no una assignació de ports. Dos serveis en un mateix amfitrió no es poden separar amb això, i un protocol que incrusta adreces IP dins de la seva càrrega útil encara veurà les reals.
L'assignació no crea cap camí de tornada
La traducció passa al client, així que el servidor encara ha d'encaminar les respostes cap al túnel i el seu tallafoc encara les ha de permetre. Si la passarel·la remota no sap com arribar a la subxarxa del túnel, la petició arriba i la resposta surt per la porta equivocada; l'assignació només fa que la fallada sembli un problema del client.
Les regles del costat del servidor haurien de descriure les adreces que existeixen al servidor després de la traducció, no el rang visible pel client. Copiar l'àlies en una regla de permís malbarata una tarda, perquè cap paquet d'aquell costat no el porta.
Trieu un rang d'àlies que no entri en conflicte amb res més que el client encamini: una altra VPN, una xarxa de contenidors, una segona oficina. Un conflicte aquí reintrodueix l'ambigüitat original sota un número diferent i és més difícil de veure perquè les adreces semblen desconegudes.
Els noms i les càrregues útils sobreviuen a la traducció
Un nom d'amfitrió que es resol a la 192.168.1.20 real envia el navegador al dispositiu local en lloc del remot, digui el que digui la taula d'encaminament. La resposta del DNS privat ha d'apuntar al rang visible pel client, mentre que el certificat TLS encara porta el nom que l'aplicació espera. Proveu amb el nom i no amb l'adreça, perquè l'adreça pot funcionar mentre el nom es resol en silenci en la direcció equivocada. Quan la passarel·la remota també serveix aquella zona, els seus propis registres també necessiten el rang visible pel client.
Les redireccions, les URL incrustades i les aplicacions que lliuren la seva pròpia adreça en una càrrega útil es poden trencar de maneres que cap assignació de paquets pot reparar. Tracteu-les com un problema d'aplicació i dimensionueu l'esforç en conseqüència abans de prometre que renumerar no cal.
Tres comprovacions abans de comprometre-us
Primer, confirmeu la implementació del client. Community OpenVPN admet aquesta opció; la base de codi d'OpenVPN 3 la llista entre les funcions no admeses, així que un perfil enviat a un client d'estil Connect pot simplement ignorar-la. Una directiva que s'accepta i no s'aplica mai és pitjor que un error, perquè el túnel sembla saludable.
Segon, verifiqueu la ruta i la traducció per separat amb una finestra de diagnòstic curta a alta verbositat, i després proveu el servei real en lloc d'un ping. Tercer, confirmeu que el router local i el recurs remot continuen sent distingibles des del client, ja que aquest era l'objectiu original.
Si el client no pot fer la traducció, demaneu ajuda al costat de la passarel·la o accepteu una renumeració. Afegir més rutes per a la mateixa adreça no és un disseny.