To lokasjoner, ett subnett: bygg en aliasvisning for hver

To kundelokasjoner kjører begge 192.168.50.0/24, og en fjerningeniør må nå en skriver på samme adresse på hver av dem. Ingen rutertriks løser denne tvetydigheten alene. Hver lokasjon trenger en egen adressevisning, og gatewayen må velge lokasjonen fra den visningen før den videresender noe.

Planen har fire deler: aliasprefikser, begge oversettelsesretninger, overleggpolicy og navn. Hver del må stemme med de andre.

Velg én aliasprefiks per lokasjon

Tildel hver lokasjon en hel aliasprefiks som ikke tilhører noen andre i miljøet. En plan for to lokasjoner kan mappe lokasjon A sin 192.168.50.0/24 til 172.21.10.0/24 og lokasjon B sitt identiske LAN til 172.21.20.0/24. Kontroller kandidatene mot hvert deltakende nettverk, inkludert sky-VPC-er og andre VPN-pooler. Privat adresseområde deles av enhver organisasjon, så det at et område er RFC 1918 sier ingenting om at det er ledig her.

Publiser aliaset, ikke det opprinnelige subnettet, til fjernbrukere. Det opprinnelige området forblir en lokal kjensgjerning.

Oversett i begge retninger

Oversett i begge retninger. Destinasjonsmapping skriver om en aliasadresse til den opprinnelige adressen på lokasjonen som eier den. Kildemapping skriver om den eksterne kalleparten til et alias som andre lokasjoner kan skille.

Statisk en-til-en-mapping er deterministisk, og det gjør ikke implementasjonen tilstandsløs. Omvendt oversettelse kan avhenge av tilkoblingstilstand, og failover eller asymmetriske stier kan ødelegge en plan som ignorerer det. Plattformens dokumentasjon avgjør hvilke av disse som gjelder.

Det nøyaktige trinnet der policy, selektorer og ruter gjelder, varierer mellom policybasert IPsec, rutbaserte tunneler og andre produkter. Design for den du kjører.

Bær planen gjennom overlegget

I et hub tildeler du hver aliasprefiks til lokasjonsstien som eier den, og tillater bare transitten oppgaven trenger. I et mesh trenger hver relevant peer samme prefiks og policykunnskap. Å legge til tunneler fikser ikke tvetydig adressering i seg selv.

Publisering av hele subnettet er bredere enn publisering av én tjeneste. Hvis bare noen få maskiner eller porter trengs, hold tilgangsreglene snevrere enn mappingen.

Hodeoversettelse skriver ikke om applikasjonsnyttelasten. Omadresseringer, innebygde adresser i konfigurasjonsfiler og kildestyrte tillatelser kan fortsatt bære den opprinnelige adressen. Test applikasjonsstien, ikke bare ping. Et fungerende ICMP-svar beviser at mappingen finnes og sier ingenting om hvorvidt applikasjonen godtar aliaset.

Rett opp navnene hver kallepart ser

Gi vedlikeholdsnavn svar som passer med kallepartens visning. Hvis fjerningeniøren slår opp et vertsnavn, bør det returnere aliasadressen for den lokasjonen, ikke det delte opprinnelige området.

Kontroller DNS-visninger per lokasjon før det første vedlikeholdsvinduet. Et navn som løses til det opprinnelige subnettet, sender kalleparten tilbake til tvetydigheten planen skulle fjerne.

Registrer og verifiser per lokasjon

Godta hver lokasjon separat fra en ekte kallepart og bekreft hvilken maskin som svarte. Registrer den opprinnelige adressen, aliaset, gatewayen som eier det og den tillatte tjenesten sammen.

Det er denne oversikten som bevarer skillet når en tredje lokasjon dukker opp med samme standard-LAN. Veiledningen for policybasert IPsec NAT dokumenterer én konkret oversettelsesmodell; den er ikke en kontrakt for alle plattformer.