Dous sitios, unha subrede: cree unha vista de alias para cada un

Dous sitios de cliente executan ambos 192.168.50.0/24, e un enxeñeiro remoto debe chegar a unha impresora no mesmo enderezo en cada un. Ningún truco de encamiñamento resolve esa ambigüidade por si só. Cada sitio necesita unha vista de enderezos distinta, e a pasarela debe escoller o sitio desde esa vista antes de reenviar nada.

O plan ten catro partes: prefixos de alias, ambas direccións de tradución, política de superposición e nomes. Cada unha debe concordar coas demais.

Escolla un prefixo de alias por sitio

Asigne a cada sitio un prefixo de alias completo que non pertenza a ninguén máis na contorna. Un plan de dous sitios podería mapear 192.168.50.0/24 do sitio A a 172.21.10.0/24 e a LAN idéntica do sitio B a 172.21.20.0/24. Comprobe os candidatos contra cada rede participante, incluídas VPC na nube e outros pools de VPN. O espazo de enderezos privados compárteo toda organización, así que que un rango sexa RFC 1918 non di nada sobre se está libre aquí.

Publique o alias, non a subrede nativa, aos usuarios remotos. O rango nativo segue sendo un feito local.

Traduza nas dúas direccións

Traduza nas dúas direccións. A mapación de destino reescribe un enderezo de alias no enderezo nativo no sitio propietario. A mapación de orixe reescribe o chamante remoto nun alias que outros sitios poden distinguir.

Unha mapación estática un-a-un é determinista, e iso non fai que a implementación non teña estado. A tradución inversa pode depender do estado da conexión, e o failover ou as rutas asimétricas poden romper un plan que o ignore. A documentación da plataforma decide cal deses casos se aplica.

A etapa exacta na que se aplican a política, os selectores e as rutas difire entre IPsec baseado en políticas, túneles baseados en rutas e outros produtos. Deseñe para o que execute.

Leve o plan a través da superposición

Nun concentrador, asigne cada prefixo de alias á ruta do sitio que o posúe e permita só o tránsito que a tarefa necesita. Nunha malla, cada par relevante necesita o mesmo prefixo e coñecemento da política. Engadir túneles non arranxa o enderezamento ambiguo por si só.

A publicación de toda a subrede é máis ampla que a dun só servizo. Se só se necesitan unhas poucas máquinas ou portos, manteña as regras de acceso máis estreitas que a mapación.

A tradución de cabeceira non reescribe as cargas útiles da aplicación. As redireccións, os enderezos incrustados nos ficheiros de configuración e os permisos baseados na orixe poden seguir levando o enderezo nativo. Probe a ruta da aplicación, non só o ping. Unha resposta ICMP que funciona demostra que a mapación existe e non di nada sobre se a aplicación acepta o alias.

Corrixa os nomes que ve cada chamante

Dea aos nomes de mantemento respostas que coincidan coa vista do chamante. Se o enxeñeiro remoto resolve un nome de host, debería devolver o enderezo de alias dese sitio, non o rango nativo compartido.

Comprobe as vistas DNS por sitio antes da primeira ventá de mantemento. Un nome que resolve á subrede nativa devolve o chamante á ambigüidade que o plan debía eliminar.

Rexiste e verifique por sitio

Acepte cada sitio por separado desde un chamante real e confirme que máquina respondeu. Rexiste xuntos o enderezo nativo, o alias, a pasarela propietaria e o servizo permitido.

Ese inventario é o que preserva a distinción cando chega un terceiro sitio coa mesma LAN predeterminada. A guía de IPsec NAT baseado en políticas documenta un modelo de tradución concreto; non é un contrato para todas as plataformas.