Kiedy NAT wewnątrz VPN typu site-to-site zasługuje na swoje miejsce

Obie lokalizacje używają tej samej puli prywatnej, a tunel wstaje, podczas gdy nic użytecznego przez niego nie przechodzi. Tłumaczenie jest zwykłą odpowiedzią i jest to prawdziwa odpowiedź: przedstawienie innego zakresu drugiej stronie może rozwiązać nakładanie się lub ścieżkę powrotną, której druga sieć nie potrafi trasować. Pomijana część polega na tym, że tłumaczenie zmienia adresy, które widzi każda późniejsza decyzja. Traktuj to jako udokumentowaną decyzję projektową z zapisanym mapowaniem, a nie jako regułę dodawaną, aż ping się powiedzie.

Zdecyduj, który adres jest przepisywany

Tłumaczenie źródła zmienia to, co zdalna usługa i jej logi widzą jako klienta, więc host oddziału staje się adresem bramy po przybyciu. Tłumaczenie miejsca docelowego lub prefiksu przedstawia zamiast tego alternatywny adres zasobu zdalnego. Niektóre wdrożenia wymagają skoordynowanego tłumaczenia po obu stronach, aby rozdzielić dwie skądinąd identyczne sieci, i w tej kombinacji zaczyna się większość zamieszania.

Zapisz źródło przed tłumaczeniem, miejsce docelowe tak, jak nazywa je aplikacja, oraz parę adresów, na którą pasuje każda brama. Trzy kolumny wystarczą, a trzecia kolumna to ta, którą ludzie pomijają.

Kolejność selektorów też ma znaczenie. Wybór i tłumaczenie polityki IPsec odbywają się na określonych etapach, więc selektor napisany dla adresów sprzed tłumaczenia może nigdy nie pasować do pakietu na etapie, który założyłeś. Sprawdź politykę zainstalowaną, a nie tę, którą zamierzałeś zainstalować, ponieważ obie rozchodzą się dokładnie wtedy, gdy regułę akceptuje jeden komponent, a inny ją ignoruje:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Śledź ładunek i ścieżkę powrotną

Serwer, który rejestruje przetłumaczone źródło zamiast pojedynczego hosta oddziału, zepsuje każdą regułę lub raport powiązany z oryginalnym adresem. Zanim zmienisz mapowanie, sprawdź, czy coś poniżej podejmuje decyzję na podstawie tego pola: listy dostępu, raporty audytu, limity szybkości, kontrole licencji. Każde z nich jest miejscem, w którym tłumaczenie później objawia się jako niewyjaśniona awaria.

Protokoły przenoszące adresy w swoim ładunku wymagają osobnego planowania, ponieważ przepisanie zewnętrznego nagłówka nie dotyka wewnętrznego odwołania. Aktywny FTP, SIP i niektóre produkty dostępu zdalnego to klasyczne przypadki, a projekt, który je ignoruje, będzie działał dla ruchu webowego i zawiedzie dla aplikacji, która miała znaczenie.

Ruch powrotny zależy od mapowań stanowych. Przełączenie bramy może utracić ten stan, routing asymetryczny może go ominąć, a restart może go wyczyścić, podczas gdy sesje pozostają otwarte po drugiej stronie. Dlatego żądanie, które dociera do celu, i sesja, która się kończy, to dwa różne wyniki akceptacji.

Zestaw to z przenumerowaniem lokalizacji

Przenumerowanie jednej kolidującej lokalizacji usuwa mapowanie całkowicie i pozostawia plan adresacji, który można czytać bez tabel tłumaczeń. Jest to kosztowne operacyjnie: rekordy DNS, przypisania statyczne, reguły zapory i każdy udokumentowany adres muszą zmienić się razem. Koszt pojawia się raz, w zaplanowanym oknie, z jasnym stanem końcowym. Kupujesz możliwość odczytania zrzutu pakietów lata później bez tabeli wyszukiwania.

Tłumaczenie unika większości lokalnych zmian i tworzy mapowanie, które trzeba utrzymywać w DNS, dokumentacji i rozwiązywaniu problemów na zawsze. Koszt pojawia się ciągle, w postaci każdego przyszłego inżyniera, który musi się nauczyć, że jeden prefiks wewnątrz tunelu znaczy coś innego.

Dla połączenia tymczasowego lub sieci partnerskiej, której nie kontrolujesz, ciągły koszt zwykle się opłaca. Dla dwóch lokalizacji, które posiadasz i będziesz posiadać latami, przenumerowanie jest często tańszą decyzją, gdy migrację policzy się uczciwie.

Udowodnij oba kierunki prawdziwą sesją

Testuj sesję aplikacji, a nie pojedynczą sondę. Udane żądanie echa dowodzi, że jeden kierunek jednego protokołu działa, i jest całkowicie zgodne ze ścieżką powrotną, która zawodzi dla wszystkiego stanowego. Użyj usługi, która zmotywowała projekt, i przeczytaj jej log na drugim końcu, aby zobaczyć, który adres źródłowy zapisała.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Następnie potwierdź, że przez mapowanie są osiągalne tylko zamierzone usługi. Tłumaczenie zmienia adresację i nic nie robi dla autoryzacji, więc polityka zapory nadal decyduje, co jest dozwolone. Projekt, który opiera się na niejasnym przetłumaczonym prefiksie jako kontroli dostępu, nie ma żadnej kontroli dostępu.

Zapisz mapowanie, przetestowaną sesję i adresy zaobserwowane przez każdą stronę. Następna osoba, która będzie debugować ten tunel, potrzebuje tych trzech faktów bardziej niż pliku konfiguracji.