Två platser, ett subnät: bygg en aliasvy för var och en

Två kundplatser kör båda 192.168.50.0/24, och en fjärringenjör måste nå en skrivare på samma adress på var och en. Inget routingtrick löser den tvetydigheten på egen hand. Varje plats behöver en egen adressvy, och gatewayen måste välja plats utifrån den vyn innan den vidarebefordrar något.

Planen har fyra delar: aliasprefix, båda översättningsriktningarna, overlaypolicy och namn. Varje del måste stämma med de andra.

Välj ett aliasprefix per plats

Tilldela varje plats ett helt aliasprefix som inte tillhör någon annan i miljön. En plan för två platser kan mappa plats A:s 192.168.50.0/24 till 172.21.10.0/24 och plats B:s identiska LAN till 172.21.20.0/24. Kontrollera kandidaterna mot varje deltagande nätverk, inklusive moln-VPC:er och andra VPN-pooler. Privat adressutrymme delas av varje organisation, så att ett intervall är RFC 1918 säger ingenting om att det är ledigt här.

Publicera aliaset, inte det ursprungliga subnätet, till fjärranvändare. Det ursprungliga intervallet förblir ett lokalt faktum.

Översätt åt båda hållen

Översätt åt båda hållen. Destinationsmappning skriver om en aliasadress till den ursprungliga adressen på platsen som äger den. Källmappning skriver om fjärranroparen till ett alias som andra platser kan skilja ut.

Statisk en-till-en-mappning är deterministisk, och det gör inte implementeringen tillståndslös. Omvänd översättning kan bero på anslutningens tillstånd, och failover eller asymmetriska vägar kan bryta en plan som ignorerar det. Plattformens dokumentation avgör vilket av dessa som gäller.

Det exakta steget där policy, selektorer och rutter gäller skiljer sig mellan policybaserad IPsec, ruttbaserade tunnlar och andra produkter. Designa för den du kör.

Bär planen genom overlayen

I ett hub tilldelar du varje aliasprefix till den platsväg som äger det och tillåter bara den transit som uppgiften behöver. I ett mesh behöver varje relevant peer samma prefix och policykunskap. Att lägga till tunnlar löser inte tvetydig adressering i sig.

Publicering av hela subnätet är bredare än publicering av en enda tjänst. Om bara några få maskiner eller portar behövs, håll åtkomstreglerna snävare än mappningen.

Huvudöversättning skriver inte om applikationsnyttolaster. Omdirigeringar, inbäddade adresser i konfigurationsfiler och källbaserade behörigheter kan alla fortfarande bära den ursprungliga adressen. Testa applikationsvägen, inte bara ping. Ett fungerande ICMP-svar bevisar att mappningen finns och säger ingenting om huruvida applikationen accepterar aliaset.

Rätta namnen som varje anropare ser

Ge underhållsnamn svar som matchar anroparens vy. Om fjärringenjören slår upp ett värdnamn bör det returnera aliasadressen för den platsen, inte det delade ursprungliga intervallet.

Kontrollera DNS-vyer per plats före det första underhållsfönstret. Ett namn som löses till det ursprungliga subnätet skickar anroparen tillbaka in i den tvetydighet som planen skulle ta bort.

Registrera och verifiera per plats

Acceptera varje plats separat från en riktig anropare och bekräfta vilken maskin som svarade. Registrera den ursprungliga adressen, aliaset, gatewayen som äger det och den tillåtna tjänsten tillsammans.

Det är den inventeringen som bevarar skillnaden när en tredje plats dyker upp med samma standard-LAN. Vägledningen för policybaserad IPsec NAT dokumenterar en konkret översättningsmodell; den är inte ett avtal för alla plattformar.