Dwie lokalizacje, jedna podsieć: zbuduj osobny widok aliasów dla każdej

Dwie lokalizacje klienta używają obie 192.168.50.0/24, a zdalny inżynier musi dotrzeć do drukarki pod tym samym adresem w każdej z nich. Żaden trik routingu nie rozwiązuje tej niejednoznaczności sam. Każda lokalizacja potrzebuje odrębnego widoku adresów, a brama musi wybrać lokalizację z tego widoku, zanim cokolwiek przekaże.

Plan ma cztery części: prefiksy aliasów, oba kierunki tłumaczenia, politykę nakładki i nazwy. Każda musi zgadzać się z pozostałymi.

Wybierz jeden prefiks aliasu na lokalizację

Przydziel każdej lokalizacji cały prefiks aliasu, który nie należy do nikogo innego w środowisku. Plan dla dwóch lokalizacji może mapować 192.168.50.0/24 lokalizacji A na 172.21.10.0/24, a identyczną sieć LAN lokalizacji B na 172.21.20.0/24. Sprawdź kandydatów wobec każdej uczestniczącej sieci, w tym chmur VPC i innych puli VPN. Prywatna przestrzeń adresowa jest współdzielona przez każdą organizację, więc to, że zakres jest RFC 1918, nic nie mówi o tym, czy jest tu wolny.

Publikuj alias, a nie rodzimą podsieć, użytkownikom zdalnym. Rodzimy zakres pozostaje faktem lokalnym.

Tłumacz w obu kierunkach

Tłumacz w obu kierunkach. Mapowanie docelowe przepisuje adres aliasu na adres rodzimy w lokalizacji, która go posiada. Mapowanie źródłowe przepisuje zdalnego wywołującego na alias, który inne lokalizacje potrafią odróżnić.

Statyczne mapowanie jeden do jednego jest deterministyczne, ale to nie czyni implementacji bezstanową. Tłumaczenie odwrotne może zależeć od stanu połączenia, a przełączenie awaryjne lub ścieżki asymetryczne mogą zepsuć plan, który to ignoruje. Dokumentacja platformy decyduje, który z tych przypadków ma zastosowanie.

Dokładny etap, na którym obowiązują polityka, selektory i trasy, różni się między IPsec opartym na politykach, tunelami opartymi na trasach i innymi produktami. Projektuj pod ten, który eksploatujesz.

Przeprowadź plan przez nakładkę

W koncentratorze przypisz każdy prefiks aliasu do ścieżki lokalizacji, która go posiada, i zezwalaj tylko na tranzyt potrzebny zadaniu. W sieci każdy odpowiedni peer potrzebuje tego samego prefiksu i wiedzy o polityce. Dodanie tuneli samo nie naprawia niejednoznacznego adresowania.

Publikacja całej podsieci jest szersza niż publikacja jednej usługi. Jeśli potrzebnych jest tylko kilka maszyn lub portów, trzymaj reguły dostępu węższe niż mapowanie.

Tłumaczenie nagłówków nie przepisuje ładunków aplikacji. Przekierowania, osadzone adresy w plikach konfiguracyjnych i uprawnienia oparte na źródle nadal mogą przenosić adres rodzimy. Testuj ścieżkę aplikacji, nie tylko ping. Działająca odpowiedź ICMP dowodzi, że mapowanie istnieje, i nic nie mówi o tym, czy aplikacja akceptuje alias.

Popraw nazwy, które widzi każdy wywołujący

Daj nazwom utrzymaniowym odpowiedzi zgodne z widokiem wywołującego. Jeśli zdalny inżynier rozwiązuje nazwę hosta, powinno ona zwracać adres aliasu dla tej lokalizacji, a nie wspólny rodzimy zakres.

Sprawdź widoki DNS dla każdej lokalizacji przed pierwszym oknem utrzymaniowym. Nazwa, która rozwiązuje się do rodzimej podsieci, odsyła wywołującego do niejednoznaczności, którą plan miał usunąć.

Zapisuj i weryfikuj dla każdej lokalizacji

Przyjmij każdą lokalizację osobno od rzeczywistego wywołującego i potwierdź, która maszyna odpowiedziała. Zapisuj razem adres rodzimy, alias, bramę właściciela i dozwoloną usługę.

To ten spis zachowuje rozróżnienie, gdy pojawia się trzecia lokalizacja z tą samą domyślną siecią LAN. Przewodnik po IPsec NAT opartym na politykach dokumentuje jeden konkretny model tłumaczenia; nie jest kontraktem dla każdej platformy.