To lokasjonar, eitt subnett: bygg ein aliasvising for kvar

To kundelokasjonar køyrer begge 192.168.50.0/24, og ein fjerningeniør må nå ein skrivar på same adresse på kvar av dei. Ingen rutertriks løyser denne tvitydigheita åleine. Kvar lokasjon treng ei eiga adressevising, og gatewayen må velje lokasjonen frå den visinga før han videresender noko.

Planen har fire delar: aliasprefiks, begge omsetjingsretningar, overleggpolicy og namn. Kvar del må stemme med dei andre.

Vel éin aliasprefiks per lokasjon

Tildel kvar lokasjon ein heil aliasprefiks som ikkje høyrer til nokon andre i miljøet. Ein plan for to lokasjonar 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 kandidatane mot kvart deltakande nettverk, inkludert sky-VPC-ar og andre VPN-poolar. Privat adresseområde blir delt av kvar organisasjon, så det at eit område er RFC 1918 seier ingenting om at det er ledig her.

Publiser aliaset, ikkje det opphavlege subnettet, til fjernbrukarar. Det opphavlege området blir verande ein lokal kjensgjerning.

Omset i begge retningar

Omset i begge retningar. Destinasjonsmapping skriv om ei aliasadresse til den opphavlege adressa på lokasjonen som eig ho. Kjeldedata skriv om den eksterne kallaren til eit alias som andre lokasjonar kan skilje.

Statisk ein-til-ein-mapping er deterministisk, og det gjer ikkje implementasjonen tilstandslaus. Omvend omsetjing kan avhenge av tilkoplingsstatus, og failover eller asymmetriske stiar kan øydeleggje ein plan som ignorerer det. Dokumentasjonen til plattforma avgjer kva av desse som gjeld.

Det nøyaktige trinnet der policy, selektorar og ruter gjeld, varierer mellom policybasert IPsec, ruterbaserte tunnelar og andre produkt. Design for den du køyrer.

Ber planen gjennom overlegget

I eit hub tildeler du kvar aliasprefiks til lokasjonsstien som eig han, og tillèt berre transitten oppgåva treng. I eit mesh treng kvar relevant peer same prefiks og policykunnskap. Å leggje til tunnelar løyser ikkje tvitydig adressering i seg sjølv.

Publisering av heile subnettet er breiare enn publisering av éin teneste. Viss berre nokre få maskinar eller portar trengst, hald tilgangsreglane snevrare enn mappinga.

Hovudomsetjing skriv ikkje om applikasjonsnyttelasta. Omdirigeringar, innebygde adresser i konfigurasjonsfiler og kjeldebaserte løyve kan framleis bere den opphavlege adressa. Test applikasjonsstien, ikkje berre ping. Eit fungerande ICMP-svar beviser at mappinga finst og seier ingenting om korvidt applikasjonen godtek aliaset.

Rett opp namna kvar kallar ser

Gje vedlikehaldsnamn svar som passar med visinga til kallaren. Viss fjerningeniøren slår opp eit vertsnamn, bør det returnere aliasadressa for den lokasjonen, ikkje det delte opphavlege området.

Kontroller DNS-visingar per lokasjon før det første vedlikehaldsvindauget. Eit namn som blir løyst til det opphavlege subnettet, sender kallaren tilbake til tvitydigheita planen skulle fjerne.

Registrer og verifiser per lokasjon

Godta kvar lokasjon separat frå ein ekte kallar og stadfest kva maskin som svara. Registrer den opphavlege adressa, aliaset, gatewayen som eig det og den tillatne tenesta saman.

Det er denne oversikta som bevarer skiljet når ein tredje lokasjon dukkar opp med same standard-LAN. Rettleiinga for policybasert IPsec NAT dokumenterer éin konkret omsetjingsmodell; ho er ikkje ein kontrakt for alle plattformer.