Dos sedes, una subred: cree una vista de alias para cada una

Dos sedes de cliente ejecutan ambas 192.168.50.0/24, y un ingeniero remoto necesita llegar a una impresora en la misma dirección en cada una. Ningún truco de enrutamiento resuelve esa ambigüedad por sí solo. Cada sede necesita una vista de direcciones distinta, y la puerta de enlace debe elegir la sede desde esa vista antes de reenviar nada.

El plan tiene cuatro partes: prefijos de alias, ambas direcciones de traducción, política de superposición y nombres. Cada una debe concordar con las demás.

Elija un prefijo de alias por sede

Asigne a cada sede un prefijo de alias completo que no pertenezca a nadie más en el entorno. Un plan de dos sedes podría asignar 192.168.50.0/24 de la sede A a 172.21.10.0/24 y la LAN idéntica de la sede B a 172.21.20.0/24. Compruebe los candidatos contra cada red participante, incluidas VPC en la nube y otros grupos de VPN. El espacio de direcciones privadas lo comparte toda organización, así que que un rango sea RFC 1918 no dice nada sobre si está libre aquí.

Publique el alias, no la subred nativa, a los usuarios remotos. El rango nativo sigue siendo un hecho local.

Traduzca en ambas direcciones

Traduzca en ambas direcciones. La asignación de destino reescribe una dirección de alias en la dirección nativa en la sede propietaria. La asignación de origen reescribe al llamante remoto en un alias que otras sedes pueden distinguir.

Una asignación estática uno a uno es determinista, y eso no hace que la implementación no tenga estado. La traducción inversa puede depender del estado de la conexión, y la conmutación por error o las rutas asimétricas pueden romper un plan que lo ignore. La documentación de la plataforma decide cuál de esos casos se aplica.

La etapa exacta en la que se aplican la política, los selectores y las rutas difiere entre IPsec basado en políticas, túneles basados en rutas y otros productos. Diseñe para el que ejecute.

Lleve el plan a través de la superposición

En un concentrador, asigne cada prefijo de alias a la ruta de la sede que lo posee y permita solo el tránsito que la tarea necesita. En una malla, cada par relevante necesita el mismo prefijo y conocimiento de la política. Añadir túneles no arregla el direccionamiento ambiguo por sí solo.

La publicación de toda la subred es más amplia que la de un solo servicio. Si solo se necesitan unas pocas máquinas o puertos, mantenga las reglas de acceso más estrechas que la asignación.

La traducción de cabecera no reescribe las cargas útiles de la aplicación. Las redirecciones, las direcciones incrustadas en archivos de configuración y los permisos basados en origen todavía pueden llevar la dirección nativa. Pruebe la ruta de la aplicación, no solo el ping. Una respuesta ICMP que funciona demuestra que la asignación existe y no dice nada sobre si la aplicación acepta el alias.

Corrija los nombres que ve cada llamante

Dé a los nombres de mantenimiento respuestas que coincidan con la vista del llamante. Si el ingeniero remoto resuelve un nombre de host, debería devolver la dirección de alias de esa sede, no el rango nativo compartido.

Compruebe las vistas de DNS por sede antes de la primera ventana de mantenimiento. Un nombre que resuelve a la subred nativa devuelve al llamante a la ambigüedad que el plan debía eliminar.

Registre y verifique por sede

Acepte cada sede por separado desde un llamante real y confirme qué máquina respondió. Registre juntos la dirección nativa, el alias, la puerta de enlace propietaria y el servicio permitido.

Ese inventario es lo que preserva la distinción cuando llega una tercera sede con la misma LAN predeterminada. La guía de IPsec NAT basado en políticas documenta un modelo de traducción concreto; no es un contrato para todas las plataformas.