AWS Client VPN czy bastion, aby dotrzeć do VPC w peeringu

Jeden endpoint Client VPN może dotrzeć do VPC, który jest w peeringu z jego powiązanym VPC, i nie potrzebujesz bastionu, aby to było legalne. Wybór, który warto podjąć, dotyczy tego, gdzie ruch zmienia ręce: trasa endpointu, która ląduje w podsieci skojarzenia i przechodzi przez połączenie peeringu, albo host w VPC w peeringu, który kończy sesję. Obie ścieżki działają i zawodzą w różnych miejscach, więc decyzja dotyczy własności i audytu, a nie tego, co pozwala AWS. Oto jak wybieram między nimi i cztery wpisy, które sprawiają, że trasa routowana działa.

Dwie ścieżki, jeden endpoint, różni właściciele

Na trasie routowanej ruch klienta dociera do endpointu, jest tłumaczony na adres interfejsu sieciowego Client VPN w podsieci skojarzenia i opuszcza tę podsieć przez połączenie peeringu z A do B. VPC B nie kończy żadnej sesji VPN; widzi zwykły ruch z VPC A, dlatego jego trasa powrotna wskazuje VPC A, a nie pulę klientów.

Na ścieżce przez bastion klient najpierw dociera do hosta. Bastion w A nadal pozostawia ostatni skok przez połączenie peeringu, więc zachowujesz pracę peeringu i dodajesz sesję. Bastion w B także potrzebuje ścieżki od klienta, a gdy tą ścieżką jest ta sama trasa endpointu, masz projekt routowany plus jeden skok. Bastion usuwa pracę tylko wtedy, gdy już istnieje, jest już zatwierdzony, a to, co za nim stoi, potrzebuje granicy sesji, a nie granicy sieci.

Cztery wpisy sprawiają, że trasa routowana działa

AWS dokumentuje ten scenariusz na stronie Client VPN how-it-works, a w praktyce sprowadza się to do czterech wpisów należących do dwóch lub trzech zespołów. Zakresy są ilustracyjne; zakres peeringu musi być unikalny, a zakres powrotny musi pasować do twojego planu.

Trasa i uprawnienie to osobne kontrole. Poprawna trasa endpointu bez pasującej reguły autoryzacji nic nie daje klientowi; reguła autoryzacji dla celu, którego endpoint nie może routować, daje mu czarną dziurę. Obie muszą wskazywać ten sam zakres.

Trasa endpointu wskazuje podsieć we własnym VPC endpointu, nigdy połączenie peeringu. Tabele tras VPC wskazują połączenie peeringu, nigdy instancję ani interfejs. Skopiowanie wartości między nimi zapisuje się bez skargi i nic nie routuje.

Ponieważ podsieć skojarzenia tłumaczy źródło klienta, B musi routować z powrotem do VPC A, a nie do puli klientów. Wysyłanie zakresu klientów przez połączenie peeringu wygląda symetrycznie, przechodzi przegląd i zawodzi po cichu, bo B nigdy nie widzi pakietu ze źródłem klienta.

Grupy zabezpieczeń i ostatni metr uprawnienia

Routing wprowadza pakiety do B; B nadal decyduje. Dla aktywnego połączenia peeringu w tym samym regionie grupa zabezpieczeń w B może odwołać się do grupy zastosowanej do skojarzenia Client VPN, co utrzymuje regułę wąską i przeżywa zmiany adresów. Tam, gdzie odwołanie do grupy nie jest wykonalne, zezwól jawnie na zakres podsieci skojarzenia zamiast rozszerzać do 0.0.0.0/0, co zamienia błąd routingu w niewyjaśniony limit czasu.

Następnie sprawdź to, czego routing nigdy nie dotyka: listy ACL sieci na obu podsieciach, listę dozwolonych lub odbiorców tokenu aplikacji oraz DNS. Peering nie kopiuje prywatnych stref hostowanych, więc laptop może trzymać działającą trasę do adresu, którego nie potrafi rozwiązać, a połączenie peeringu nie dodaje zaufania do certyfikatu. Skieruj endpoint na resolver, który odpowiada za B, a potem potwierdź, że prywatna nazwa i certyfikat się zgadzają.

Kiedy bastion jest uczciwą odpowiedzią

Trzymam trzy wyzwalacze świadomego wyboru bastionu. VPC w peeringu należy do zespołu, który nie doda trasy powrotnej dla twojego zakresu albo nie przyjmie odwołania do grupy. Dostęp musi być zatwierdzany lub rejestrowany dla każdej sesji, a aplikacja nie może tego unieść sama. Albo ostatni skok musi zostać w B, bo usługa rozwiązuje się tylko tam, a jej tożsamość TLS jest przypięta do wewnętrznej nazwy.

Nic z tego nie jest obejściem faktu, że peering nie jest tranzytywny. Nietranzytywność ogranicza to, co mogą robić zasoby w B: nie mogą użyć A jako tranzytu do trzeciego VPC, z którym A jest w peeringu. To nigdy nie znaczyło, że użytkownik VPN nie może dotrzeć do bezpośrednio peerowanego VPC, a bastion zbudowany, aby obejść to błędne odczytanie, jest hostem, który łatany jest bez powodu.

Odwrotny błąd kosztuje więcej z czasem: przepuść każdy zespół przez jedyny istniejący bastion, a potem odkryj, że jego grupa zabezpieczeń, tabela tras i okno łatania są zależnością produkcyjną. Zapisz, któremu wyzwalaczowi służy host, i wycofaj go, gdy wyzwalacz zniknie.

Transit Gateway i kilka skojarzeń zmieniają arytmetykę

Jeśli endpoint jest podłączony bezpośrednio do Transit Gateway, a nie do podsieci, model się zmienia: klienci nie są już tłumaczeni na adres interfejsu w podsieci skojarzenia, a tabele tras bramy muszą nieść zakres klientów plus przyłączenie prowadzące do VPC w peeringu. To czystsze w skali, ale praca przenosi się z czterech wpisów do tabel tras bramy.

Kilka skojarzeń mnoży kontrole. Trasa endpointu należy do endpointu, ale każda podsieć skojarzenia potrzebuje tabeli tras z prawdziwym następnym skokiem peeringu. Sesja może się udać przez jedno skojarzenie, gdy inne nie ma trasy powrotnej, więc testuj każde.

Kolejność weryfikacji, która szybko znajduje usterkę

Wykonuj je po kolei; każdy krok może przejść, gdy następny zawodzi, a limit czasu klienta prawie nigdy nie mówi, który się złamał.

1. Rozwiąż nazwę aplikacji z klienta i sprawdź, czy adres znajduje się w zakresie peeringu.
2. Połącz się, a następnie przeczytaj dziennik połączeń endpointu dla skojarzenia, które zakończyło sesję.
3. W tej podsieci skojarzenia potwierdź, że tabela tras kieruje zakres peeringu na aktywne połączenie peeringu.
4. W podsieci zasobów w B potwierdź wpis powrotny dla zakresu interfejsu i pasujące reguły grupy.
5. Przetestuj jedną dozwoloną operację i jeden zasób, który musi pozostać nieosiągalny; drugi wyłapuje resztki debugowania.
6. Połącz się ponownie po każdej zmianie trasy split-tunnel, ponieważ działający tunel nie przyjmie nowego zestawu tras.

Dwa objawy warto zapamiętać. SYN, który dociera do B bez odpowiedzi, to prawie zawsze brakująca trasa powrotna. Połączenie, które się kończy i potem resetuje, to zwykle grupa, ACL lub aplikacja. Żaden z nich nie pojawia się w dzienniku endpointu jako przyczyna, więc trzymaj cztery wpisy z właścicielem przy każdym.

Jeśli żaden z trzech wyzwalaczy nie zachodzi, dokończ trasę routowaną i zapisz te cztery wpisy. Jeśli jeden zachodzi, zachowaj bastion tylko dla tej granicy i zostaw trasę endpointu usługom, które nie potrzebują sesji przed sobą.