To lokationer, ét subnet: byg en aliasvisning til hver

To kundelokationer kører begge 192.168.50.0/24, og en fjerneningeniør skal nå en printer på den samme adresse på hver af dem. Intet routingtrick løser den tvetydighed alene. Hver lokation har brug for en særskilt adressevisning, og gatewayen skal vælge lokationen ud fra den visning, før den videresender noget.

Planen har fire dele: aliaspræfikser, begge oversættelsesretninger, overlaypolitik og navne. Hver del skal stemme overens med de andre.

Vælg ét aliaspræfiks for hver lokation

Tildel hver lokation et helt aliaspræfiks, som ikke tilhører nogen andre i miljøet. En plan for to lokationer kan mappe lokation A’s 192.168.50.0/24 til 172.21.10.0/24 og lokation B’s identiske LAN til 172.21.20.0/24. Kontrollér kandidaterne mod hvert deltagende netværk, herunder cloud-VPC’er og andre VPN-puljer. Privat adresseområde deles af enhver organisation, så det, at et interval er RFC 1918, siger intet om, at det er ledigt her.

Udgiv aliaset, ikke det oprindelige subnet, til fjernbrugere. Det oprindelige interval forbliver en lokal kendsgerning.

Oversæt i begge retninger

Oversæt i begge retninger. Destinationsmapping omskriver en aliasadresse til den oprindelige adresse på den ejende lokation. Kildemapping omskriver den fjernkalder til et alias, som andre lokationer kan skelne.

Statisk en-til-en-mapping er deterministisk, og det gør ikke implementeringen tilstandsløs. Omvendt oversættelse kan afhænge af forbindelsestilstand, og failover eller asymmetriske stier kan ødelægge en plan, der ignorerer det. Platformens dokumentation afgør, hvilke af disse der gælder.

Det præcise trin, hvor politik, selektorer og ruter anvendes, varierer mellem politikbaseret IPsec, rutbaserede tunneler og andre produkter. Design til den, du kører.

Bær planen gennem overlayet

I et hub tildeler du hvert aliaspræfiks til den lokationssti, der ejer det, og tillader kun den transit, opgaven kræver. I et mesh har hver relevant peer brug for det samme præfiks og den samme politikviden. At tilføje tunneler løser ikke tvetydig adressering i sig selv.

Offentliggørelse af hele subnetttet er bredere end offentliggørelse af én tjeneste. Hvis der kun er brug for få maskiner eller porte, så hold adgangsreglerne snævrere end mappingen.

Headeroversættelse omskriver ikke applikationsnyttelaster. Omdirigeringer, indlejrede adresser i konfigurationsfiler og kildestyrede tilladelser kan stadig bære den oprindelige adresse. Test applikationsstien, ikke kun ping. Et fungerende ICMP-svar beviser, at mappingen findes, og siger intet om, hvorvidt applikationen accepterer aliaset.

Ret de navne, hver kalder ser

Giv vedligeholdelsesnavne svar, der matcher kalderens visning. Hvis fjerneningeniøren slår et værtsnavn op, skal det returnere aliasadressen for den lokation, ikke det delte oprindelige interval.

Kontrollér DNS-visninger for hver lokation inden det første vedligeholdelsesvindue. Et navn, der opløses til det oprindelige subnet, sender kalderen tilbage i den tvetydighed, planen skulle fjerne.

Registrér og verificér for hver lokation

Accepter hver lokation separat fra en rigtig kalder, og bekræft, hvilken maskine der svarede. Registrér den oprindelige adresse, aliaset, den ejende gateway og den tilladte tjeneste sammen.

Det er denne fortegnelse, der bevarer forskellen, når en tredje lokation dukker op med det samme standard-LAN. Den politikbaserede IPsec NAT-vejledning dokumenterer én konkret oversættelsesmodel; den er ikke en kontrakt for alle platforme.