Dois sites, uma sub-rede: crie uma vista de alias para cada um

Dois sites de cliente executam ambos 192.168.50.0/24, e um engenheiro remoto tem de chegar a uma impressora no mesmo endereço em cada um. Nenhum truque de encaminhamento resolve essa ambiguidade sozinho. Cada site precisa de uma vista de endereços distinta, e o gateway tem de escolher o site a partir dessa vista antes de encaminhar seja o que for.

O plano tem quatro partes: prefixos de alias, ambos os sentidos de tradução, política de sobreposição e nomes. Cada uma tem de concordar com as outras.

Escolha um prefixo de alias por site

Atribua a cada site um prefixo de alias inteiro que não pertença a mais ninguém no ambiente. Um plano de dois sites pode mapear 192.168.50.0/24 do site A para 172.21.10.0/24 e a LAN idêntica do site B para 172.21.20.0/24. Verifique os candidatos contra cada rede participante, incluindo VPC na nuvem e outros pools de VPN. O espaço de endereços privados é partilhado por todas as organizações, por isso ser RFC 1918 não diz nada sobre estar livre aqui.

Publique o alias, não a sub-rede nativa, para os utilizadores remotos. O intervalo nativo continua a ser um facto local.

Traduza nos dois sentidos

Traduza nos dois sentidos. O mapeamento de destino reescreve um endereço de alias no endereço nativo no site proprietário. O mapeamento de origem reescreve o chamador remoto num alias que outros sites conseguem distinguir.

Um mapeamento estático um-para-um é determinístico, e isso não torna a implementação sem estado. A tradução inversa pode depender do estado da ligação, e o failover ou caminhos assimétricos podem quebrar um plano que o ignore. A documentação da plataforma decide qual destes casos se aplica.

A fase exata em que a política, os seletores e as rotas se aplicam difere entre IPsec baseado em políticas, túneis baseados em rotas e outros produtos. Projete para o que executa.

Leve o plano através da sobreposição

Num hub, atribua cada prefixo de alias ao caminho do site que o possui e permita apenas o trânsito de que a tarefa necessita. Numa malha, cada par relevante precisa do mesmo prefixo e do mesmo conhecimento da política. Acrescentar túneis não corrige o endereçamento ambíguo por si só.

A publicação de toda a sub-rede é mais ampla do que a publicação de um único serviço. Se só são necessárias algumas máquinas ou portas, mantenha as regras de acesso mais estreitas do que o mapeamento.

A tradução de cabeçalho não reescreve as cargas úteis da aplicação. Os redirecionamentos, os endereços incorporados nos ficheiros de configuração e as permissões baseadas na origem podem continuar a transportar o endereço nativo. Teste o caminho da aplicação, não apenas o ping. Uma resposta ICMP funcional prova que o mapeamento existe e não diz nada sobre se a aplicação aceita o alias.

Corrija os nomes que cada chamador vê

Dê aos nomes de manutenção respostas que correspondam à vista do chamador. Se o engenheiro remoto resolver um nome de anfitrião, deverá devolver o endereço de alias desse site, não o intervalo nativo partilhado.

Verifique as vistas DNS por site antes da primeira janela de manutenção. Um nome que resolve para a sub-rede nativa devolve o chamador à ambiguidade que o plano devia remover.

Registe e verifique por site

Aceite cada site separadamente de um chamador real e confirme que máquina respondeu. Registe em conjunto o endereço nativo, o alias, o gateway proprietário e o serviço permitido.

É esse inventário que preserva a distinção quando chega um terceiro site com a mesma LAN predefinida. O guia de IPsec NAT baseado em políticas documenta um modelo de tradução concreto; não é um contrato para todas as plataformas.