Due sedi, una sottorete: create una vista di alias per ciascuna

Due sedi cliente eseguono entrambe 192.168.50.0/24, e un ingegnere remoto deve raggiungere una stampante allo stesso indirizzo in ciascuna. Nessun trucco di routing risolve quell’ambiguità da solo. Ogni sede ha bisogno di una vista di indirizzi distinta, e il gateway deve scegliere la sede da quella vista prima di inoltrare qualcosa.

Il piano ha quattro parti: prefissi di alias, entrambe le direzioni di traduzione, politica di sovrapposizione e nomi. Ognuna deve concordare con le altre.

Scegliete un prefisso di alias per sede

Assegnate a ogni sede un prefisso di alias intero che non appartenga a nessun altro nell’ambiente. Un piano per due sedi potrebbe mappare 192.168.50.0/24 della sede A su 172.21.10.0/24 e la LAN identica della sede B su 172.21.20.0/24. Verificate i candidati contro ogni rete partecipante, incluse le VPC cloud e gli altri pool VPN. Lo spazio di indirizzi privati è condiviso da ogni organizzazione, quindi il fatto che un intervallo sia RFC 1918 non dice nulla sulla sua disponibilità qui.

Pubblicate l’alias, non la sottorete nativa, agli utenti remoti. L’intervallo nativo resta un fatto locale.

Traducete in entrambe le direzioni

Traducete in entrambe le direzioni. La mappatura di destinazione riscrive un indirizzo di alias nell’indirizzo nativo presso la sede proprietaria. La mappatura di origine riscrive il chiamante remoto in un alias che le altre sedi possono distinguere.

Una mappatura statica uno-a-uno è deterministica, e ciò non rende l’implementazione senza stato. La traduzione inversa può dipendere dallo stato della connessione, e il failover o i percorsi asimmetrici possono rompere un piano che lo ignora. La documentazione della piattaforma decide quale di questi casi si applica.

La fase esatta in cui si applicano politica, selettori e rotte differisce tra IPsec basato su policy, tunnel basati su rotte e altri prodotti. Progettate per quello che eseguite.

Portate il piano attraverso la sovrapposizione

In un hub, assegnate ogni prefisso di alias al percorso della sede che lo possiede e consentite solo il transito necessario all’attività. In una mesh, ogni peer rilevante necessita dello stesso prefisso e della stessa conoscenza della politica. Aggiungere tunnel non corregge l’indirizzamento ambiguo da solo.

La pubblicazione dell’intera sottorete è più ampia di quella di un singolo servizio. Se servono solo poche macchine o porte, mantenete le regole di accesso più strette della mappatura.

La traduzione di intestazione non riscrive i payload delle applicazioni. I reindirizzamenti, gli indirizzi incorporati nei file di configurazione e le autorizzazioni basate sull’origine possono ancora trasportare l’indirizzo nativo. Testate il percorso dell’applicazione, non solo il ping. Una risposta ICMP funzionante dimostra che la mappatura esiste e non dice nulla sul fatto che l’applicazione accetti l’alias.

Correggete i nomi che ogni chiamante vede

Date ai nomi di manutenzione risposte che corrispondano alla vista del chiamante. Se l’ingegnere remoto risolve un nome host, dovrebbe restituire l’indirizzo di alias di quella sede, non l’intervallo nativo condiviso.

Verificate le viste DNS per sede prima della prima finestra di manutenzione. Un nome che risolve nella sottorete nativa riporta il chiamante nell’ambiguità che il piano doveva rimuovere.

Registrate e verificate per sede

Accettate ogni sede separatamente da un chiamante reale e confermate quale macchina ha risposto. Registrate insieme l’indirizzo nativo, l’alias, il gateway proprietario e il servizio consentito.

È quell’inventario a preservare la distinzione quando arriva una terza sede con la stessa LAN predefinita. La guida IPsec NAT basata su policy documenta un modello di traduzione concreto; non è un contratto per ogni piattaforma.