La misma subred en ambos extremos: asigne la LAN remota a un rango libre

La casa y la oficina usan ambas 192.168.1.0/24, así que una petición a 192.168.1.1 tiene dos respuestas posibles y el cliente elige una sin preguntar. Renumerar una red de oficina en funcionamiento rara vez es popular, y las direcciones del router suelen estar incrustadas en impresoras, cámaras y documentación. La asignación de direcciones en el lado del cliente puede presentar la red remota bajo un rango libre en su lugar, y la parte de host puede seguir igual para que 192.168.1.20 aparezca como 10.203.41.20. La trampa es que solo algunos clientes la implementan y no hace nada por la ruta de vuelta.

Dos vistas del mismo host

La asignación conserva la parte de host y cambia solo la parte de red. La misma máquina responde entonces en dos direcciones según dónde se sitúe. Escribir ambas columnas antes de configurar nada evita una mala lectura posterior de los registros y de las reglas del cortafuegos.

Los dispositivos locales de casa conservan sus propias direcciones 192.168.1.x, y ese es el objetivo del ejercicio. La impresora de la habitación contigua sigue siendo accesible mientras la oficina aparece bajo un rango que no entra en conflicto.

El orden de los argumentos es todo el truco

La opción toma una dirección, una red y máscara, y un alias: la primera red es lo que ve el cliente, el alias es lo que ve el servidor. Para los recursos que viven detrás de la puerta de enlace remota, la dirección es la forma de destino. Invertir las dos redes porque el último argumento se llama alias es el error que produce un túnel que se conecta y no asigna nada.

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 es lo que envía los paquetes del cliente para el nuevo rango al túnel; la traducción reescribe el destino durante el paso. Una respuesta de 192.168.1.20 se reescribe de vuelta a 10.203.41.20 para que el socket del cliente siga siendo coherente. Un solo host funciona igual con una máscara de longitud completa, siempre que la ruta y la asignación describan la misma dirección.

Esto es una asignación de direcciones, no una asignación de puertos. Dos servicios en un mismo host no se pueden separar con ella, y un protocolo que incrusta direcciones IP dentro de su carga útil seguirá viendo las reales.

La asignación no crea una ruta de vuelta

La traducción ocurre en el cliente, así que el servidor todavía tiene que encaminar las respuestas al túnel y su cortafuegos todavía tiene que permitirlas. Si la puerta de enlace remota no sabe cómo llegar a la subred del túnel, la petición llega y la respuesta sale por la puerta equivocada; la asignación solo hace que el fallo parezca un problema del cliente.

Las reglas del lado del servidor deberían describir las direcciones que existen en el servidor después de la traducción, no el rango visible para el cliente. Copiar el alias en una regla de permiso malgasta una tarde, porque ningún paquete de ese lado lo lleva.

Elija un rango de alias que no entre en conflicto con nada más que el cliente encamine: otra VPN, una red de contenedores, una segunda oficina. Un conflicto aquí reintroduce la ambigüedad original bajo un número distinto y es más difícil de ver porque las direcciones parecen desconocidas.

Los nombres y las cargas útiles sobreviven a la traducción

Un nombre de host que se resuelve a la 192.168.1.20 real envía el navegador al dispositivo local en lugar del remoto, diga lo que diga la tabla de enrutamiento. La respuesta del DNS privado tiene que apuntar al rango visible para el cliente, mientras que el certificado TLS sigue llevando el nombre que la aplicación espera. Pruebe con el nombre en lugar de con la dirección, porque la dirección puede funcionar mientras el nombre se resuelve en silencio en la dirección equivocada. Cuando la puerta de enlace remota también sirve esa zona, sus propios registros también necesitan el rango visible para el cliente.

Las redirecciones, las URL incrustadas y las aplicaciones que entregan su propia dirección en una carga útil pueden romperse de formas que ninguna asignación de paquetes puede reparar. Trátelas como un problema de aplicación y dimensione el esfuerzo en consecuencia antes de prometer que renumerar no es necesario.

Tres comprobaciones antes de comprometerse

Primero, confirme la implementación del cliente. Community OpenVPN admite esta opción; la base de código de OpenVPN 3 la incluye entre las funciones no admitidas, así que un perfil empujado a un cliente de estilo Connect puede simplemente ignorarla. Una directiva que se acepta y nunca se aplica es peor que un error, porque el túnel parece saludable.

Segundo, verifique la ruta y la traducción por separado con una ventana de diagnóstico breve a alta verbosidad, y luego pruebe el servicio real en lugar de un ping. Tercero, confirme que el router local y el recurso remoto siguen siendo distinguibles desde el cliente, ya que ese era el objetivo original.

Si el cliente no puede hacer la traducción, pida ayuda al lado de la puerta de enlace o acepte una renumeración. Añadir más rutas para la misma dirección no es un diseño.