AWS Site-to-Site VPN do NAT Gateway: VGW kontra Transit Gateway

Za pierwszym razem wszyscy rysują ten sam schemat: VPN do VPC, NAT gateway na zewnątrz do internetu, gotowe. AWS nie obsługuje jednak tej ścieżki, gdy VPN kończy się na virtual private gateway, a błąd jest tak cichy, że zespoły budują go ponownie więcej niż raz. Działający projekt wymaga transit gateway, co zmienia bramę i tabele tras po obu stronach. Porównaj oba kształty, zanim cokolwiek narysujesz.

Topologia, która wygląda oczywiście i nie jest obsługiwana

Dokumentacja NAT gateway AWS rysuje linię, która zaskakuje każdego, kto budował tylko projekty z jedną VPC: ruchu z połączenia Site-to-Site VPN nie można kierować do NAT gateway przez virtual private gateway. Typ bramy, na której kończy się VPN, decyduje o tym, czy ścieżka translacji w ogóle istnieje. Błąd przetrwa, bo tunel ma stan UP, a instancja EC2 w tej samej podsieci bez problemu dociera do internetu. Żadna z tych obserwacji nie sprawdza zepsutego kierunku.

W praktyce pakiet przychodzi z adresem źródłowym z sieci lokalnej i nie znajduje obsługiwanego następnego skoku, który by go przetłumaczył. W zależności od tabel jest odrzucany na granicy wyjścia, a ponieważ tunel pozostaje UP, podczas gdy instancja w tej samej podsieci nadal dociera do internetu, awaria jest zgłaszana jako problem zapory po stronie lokalnej.

Virtual private gateway kontra transit gateway

Virtual private gateway należy do jednej VPC. Kończy VPN, instaluje trasy w tabelach tej VPC i na tym się zatrzymuje. Nie ma modelu attachment, więc nie może przekazać ruchu do innej VPC ani do współdzielonego segmentu wyjścia. Ten zasięg jednej VPC to całe ograniczenie i żadna trasa dodana wewnątrz VPC tego nie zmienia.

Transit gateway to regionalne centrum, w którym VPN, każda VPC spoke i VPC usług współdzielonych pojawiają się jako attachment. Ma własne tabele tras, które wybierają, który attachment otrzyma dany prefiks.

To centrum umożliwia scentralizowane wyjście: VPN ląduje jako jeden attachment, VPC wyjścia jako drugi, a tabela tras transit gateway wysyła prefiksy kierowane do internetu z pierwszego do drugiego. Przy virtual private gateway nie ma drugiego attachment, do którego można coś wysłać, dlatego projektu nie da się załatać później.

Obsługiwana ścieżka wyjścia, skok po skoku

Projekt referencyjny ma pięć skoków i każda strzałka to decyzja routingu, którą trzeba skonfigurować. Ruch wychodzi z sieci lokalnej do attachment Site-to-Site VPN, tabela transit gateway przekazuje go do attachment VPC wyjścia, gdzie tabela podsieci wysyła go do publicznego NAT gateway. NAT gateway tłumaczy źródło, a internet gateway wynosi pakiet na zewnątrz.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Dwa szczegóły decydują, czy ostatnie skoki zadziałają. NAT gateway musi być publiczny, z elastic IP i trasą do internet gateway, ponieważ prywatny NAT gateway tłumaczy między sieciami i nigdy nie staje się wyjściem do internetu.

Zaplanuj jeden NAT gateway na każdą Availability Zone, którą chcesz obsłużyć, a każda tabela podsieci ma wskazywać na lokalny. Trzymaj tabelę transit gateway i tabele VPC jako osobne obiekty w notatkach, bo jedna wybiera attachment, a druga zasób wewnątrz VPC. Trasa domyślna tylko w jednej z nich pozostawia połowę ścieżki niezdefiniowaną i tworzy częściowe awarie, które najtrudniej przypisać.

To na ścieżce powrotnej te projekty zawodzą

NAT gateway zachowuje stan dla przepływów, które już widział, więc odpowiedzi na połączenie wychodzące wracają bez nowej reguły wejściowej. Ta właściwość nie publikuje usługi lokalnej w internecie, a traktowanie jej tak, jakby to robiła, kosztuje zespół dzień debugowania połączenia, które nigdy by nie powstało. Dla ruchu inicjowanego przez klienta muszą zgodzić się cztery trasy: polityka lokalna, tabela transit gateway, tabela podsieci wyjścia i tabela podsieci NAT. Brak tej ostatniej sprawia, że żądanie opuszcza budynek, a odpowiedź umiera wewnątrz AWS.

Sprawdź to prawdziwym klientem za VPN i zobacz, jaki publiczny adres źródłowy prezentuje. Jeśli to elastic IP NAT gateway, translacja działa; jeśli coś innego, mierzysz inne wyjście.

Asymetryczną wersję tej awarii warto rozpoznać wcześnie. Gdy tabela podsieci NAT jednej Availability Zone ma trasę powrotną do prefiksu klienta, a inna nie, nowe połączenia udają się lub zawodzą w zależności od strefy, w której ląduje przepływ, a wzorzec jest błędnie odczytywany jako niestabilny internet. Porównuj tabele podsieci dla każdej obsługiwanej strefy, zamiast naprawiać tę, w której otwarto zgłoszenie, bo brakująca trasa to cała usterka i po drugiej stronie nic nie trzeba zmieniać.

Kiedy jawny proxy jest lepszym projektem

HTTP proxy na instancji w VPC wyjścia jest uzasadnioną alternatywą i często tańszą. Klienci są konfigurowani, by z niego korzystać, proxy otwiera własne połączenie na zewnątrz, a ścieżka powrotna staje się jego problemem, a nie łamigłówką symetrycznego routingu. Dla kilku aplikacji usuwa to większość pracy z transit gateway. Daje też logi na użytkownika, których NAT gateway nie potrafi wytworzyć.

Nie jest jednak przezroczysty. Wszystko, co ignoruje ustawienia proxy, i każdy protokół, który nie jest HTTP, nie pójdą tą ścieżką.

Wybór zależy od tego, czym naprawdę mówią twoje aplikacje i ile tożsamości potrzebujesz w logach. Tam, gdzie mówią HTTP, proxy zasługuje na swoje miejsce; tam, gdzie potrzebne jest ogólne wyjście dla dowolnych protokołów, projekt z transit gateway jest tym, który obsługuje AWS. Rozstrzygnięcie tego z góry jest tańsze niż odkrycie po zbudowaniu tabel tras.