Jak kierować ruch SaaS do właściwego VPN klienta

Platforma SaaS łączy się z dwunastoma sieciami klientów, a dwóch z tych klientów używa tego samego adresu 10.20.0.10 dla swojej głównej bazy danych. Worker, który otrzyma ten adres w zadaniu, nie ma sposobu, aby ustalić, którą bazę danych ma na myśli zadanie, a współdzielona tablica trasowania chętnie wyśle je do tunelu, na który wskazuje prefiks. Rozwiązaniem nie jest więcej tuneli; rozwiązaniem jest ustalenie, gdzie tożsamość najemcy wchodzi w ścieżkę i jakiego modelu izolacji wymaga plan adresów. Trzy warunki rozstrzygają wybór: czy prefiksy klientów się nakładają, jak daleko może rozprzestrzenić się błąd i kto obsługuje łącznik.

Dwie bazy danych klientów, jeden adres docelowy

Adres IP to lokalizacja, nie tożsamość. Żądanie musi nieść najemcę, którego zweryfikował serwer, a ten najemca musi wybrać kontekst sieci, zanim zostanie rozwiązany cel.

Gdy tak się nie dzieje, awaria jest cicha. Połączenie się udaje, zapytanie działa, a odpowiedź pochodzi z bazy danych niewłaściwego klienta, ponieważ tablica trasowania miała jeden wpis dla 10.20.0.10. DNS pogarsza sprawę: nazwa w pamięci podręcznej rozwiązana w kontekście najemcy A może zostać ponownie użyta przez zadanie działające dla najemcy B. Nic w pakiecie nie odróżnia tych dwóch, więc żadna logika ponowień tego nie naprawi.

Najpierw zdecyduj o modelu izolacji

Zapisz trzy warunki przed porównywaniem produktów. Nakładanie decyduje, czy jedną przestrzeń adresową można w ogóle współdzielić; promień rażenia decyduje, czy błąd trasowania to zgłoszenie do pomocy, czy naruszenie; własność operacyjna decyduje, czy możesz prowadzić flotę łączników dla każdego najemcy.

Jeśli prefiksy są różne i polityka pozwala na kontrolowane centrum, jeden Transit Gateway z tablicami trasowania dla każdego najemcy jest wykonalny. Skojarzenie załącznika wybiera tablicę trasowania używaną dla ruchu wchodzącego z tego załącznika, a propagacja wybiera, które trasy pojawiają się w tablicy. Załącznik najemcy skojarzony tylko z własną tablicą i propagujący tylko własne prefiksy dociera do centrum i nigdzie indziej. To decyzja trasowania i pozostaje poprawna tylko dopóki nikt nie doda trasy domyślnej do współdzielonej tablicy.

Jeśli prefiksy się nakładają, samo trasowanie nie może ich rozdzielić. Potrzebujesz albo odrębnego kontekstu sieci dla każdego najemcy, albo planu tłumaczenia, który nada przestrzeni każdego klienta jednoznaczne znaczenie.

Co naprawdę oznacza izolacja Transit Gateway

Skojarzenie i propagacja to dwa najważniejsze ustawienia i łatwo je pomylić. Skojarzenie odpowiada, w której tablicy szukany jest pakiet z tego załącznika; propagacja odpowiada, które tablice uczą się tras tego załącznika. Izolacja wynika z uczynienia obu swoistymi dla najemcy, a nie z tworzenia większej liczby załączników.

Domyślna konfiguracja wszyscy-ze-wszystkimi jest wygodna i nie jest izolacją. Odrębne tablice trasowania ograniczają łączność, ale nie dają jednemu niezmienionemu adresowi docelowemu dwóch znaczeń w tym samym kontekście trasowania. Jeśli aplikacja rozwiąże 10.20.0.10, zanim pozna najemcę, warstwa trasowania już utraciła potrzebną informację.

AWS dodała 23 października 2026 NAT 1:1 na poziomie załącznika dla Transit Gateway i Cloud WAN, co zmienia odpowiedź dotyczącą nakładania dla obsługiwanych załączników. Dokumentacja NAT Transit Gateway opisuje statyczne, bezstanowe mapowania IPv4 o równym prefiksie z zachowanymi bitami hosta. Sprawdź obsługiwane typy załączników i ograniczenia regionalne, zanim zaprojektujesz wokół tego.

Powiąż zadanie ze zweryfikowanym najemcą

Każde zadanie powinno nieść tożsamość najemcy zweryfikowaną przez serwer, a ta tożsamość powinna wybrać rekord połączenia należący do administratora. Rekord wymienia zatwierdzony kontekst sieci, adres usługi, odwołanie do poświadczeń i dozwolone tam operacje. Niezaufane żądanie nigdy nie powinno dostarczać własnego identyfikatora VPN, bramy ani prywatnego celu, ponieważ ważne logowanie nie jest pozwoleniem na badanie przestrzeni adresowej każdego podłączonego klienta.

W projekcie z izolowanymi łącznikami praca najemcy A trafia do łącznika właściwego dla A, który działa w VPC A i może dotrzeć tylko do zatwierdzonych zasobów A. Odrębne kontenery na jednym hoście nie tworzą tej separacji same z siebie; przestrzenie nazw sieci, trasy i polityka wyjścia muszą ją zrealizować. Łącznik potrzebuje też poświadczeń i kolejek w zakresie najemcy, ponieważ prywatna trasa nie ogranicza współdzielonego sekretu ani współdzielonego elementu pracy. Współdzieleni workerzy aplikacji są w porządku, jeśli kontekst sieci i poświadczenia są wybierane dla każdego najemcy, a nie dla każdego hosta.

Kontrole kondycji powinny wskazywać najemcę i etap: tunel nawiązany, trasa obecna i udane rzeczywiste żądanie usługi to trzy różne sygnały. Zbiorcza liczba aktywnych tuneli ukryje tego jednego klienta, którego łącznik jest zepsuty.

Przetestuj ścieżki, które muszą zawieść

Przed uruchomieniem wykonaj trzy testy. Dozwolona operacja A musi się udać, dozwolona operacja B musi się udać, a zadanie A celowo skierowane do łącznika B lub jego przetłumaczonego aliasu musi zawieść w trybie zamkniętym. Następnie zerwij jeden tunel i potwierdź, że zadanie zawodzi tylko dla tego najemcy, bez spadania do podsieci o tym samym numerze innego klienta. Należy też przetestować odtworzenie, ponieważ nieaktualna trasa lub poświadczenia w pamięci podręcznej mogą przetrwać awarię.

Architektura może być współdzielonymi workerami z izolowanymi łącznikami albo całkowicie odrębnymi zasobami najemców. Niezmiennik jest ten sam: zweryfikowany kontekst najemcy wybiera trasę i poświadczenia, a żadna zmiana trasy nigdy nie przyznaje aplikacji uprawnień między najemcami.