Którego źródłowego adresu IP używa brama NAT AWS wobec VPN?

Otwierasz konsolę VPC, bo partner zapytał, jaki zakres źródłowy dotrze przez VPN typu lokacja-lokacja. Strona bram NAT pokazuje publiczną bramę z przypisanym Elastic IP, a pokusa jest taka, by wysłać ten adres i przejść dalej. To poprawna odpowiedź dla ścieżki internetowej i błędna dla ścieżki VPN, a różnica polega na tym, na którą bramę wskazuje tabela tras. Przejdź trasę, zanim napiszesz listę dozwolonych.

Zacznij od strony bram NAT, a nie od listy dozwolonych

Strona bram NAT podaje podsieć, typ i Elastic IP, a te trzy pola wystarczą na start. Czego nie podaje, to ścieżki, którą ruch podąża później. To wynika z tabel tras przypisanych do podsieci bramy NAT.

Najpierw przeczytaj typ, bo publiczna albo prywatna decyduje, czy później w łańcuchu pojawi się brama internetowa. Potem przeczytaj podsieć, bo tam mieszka druga trasa.

Prześledź oba tłumaczenia

Zarówno publiczne, jak i prywatne bramy NAT tłumaczą prywatne źródło IPv4 obciążenia na własny prywatny adres IPv4 bramy NAT. To pierwsze tłumaczenie odbywa się niezależnie od typu. Drugie tłumaczenie to to, o którym się zapomina: publiczna brama NAT przekazuje ruch bramie internetowej, która mapuje adres na przypisany Elastic IP.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Na ścieżce prywatnej w łańcuchu nie ma bramy internetowej. Gdy ruch wychodzi przez bramę tranzytową lub wirtualną bramę prywatną, przewodnik po bramach NAT dokumentuje prywatny adres bramy NAT jako źródło, które odbiera strona zdalna. To ten adres partner powinien dopuścić, a nie Elastic IP.

Ścieżka VPN zwykle pokazuje adres prywatny

Dla obciążenia w 10.20.1.0/24, które osiąga prefiks partnera, tabela tras podsieci obciążenia wskazuje bramę NAT, a tabela tras podsieci bramy NAT wskazuje ścieżkę bramy prywatnej. Oba przeskoki się liczą, a tylko drugi decyduje, co widzi partner. Jeśli podsieć NAT nie ma trasy do ścieżki VPN, pakiet nigdy nie dotrze, a to jest inna awaria niż błędny adres źródłowy.

Zweryfikuj tę drugą trasę, zanim w ogóle zaczniesz mówić o adresach. Brakująca trasa i błędnie zgłoszone źródło wyglądają identycznie dla partnera, który po prostu nie widzi ruchu.

Gdy drugie tłumaczenie zmienia odpowiedź

AWS oferuje też jawne, pasujące mapowanie NAT jeden do jednego na załączniku bramy tranzytowej. To mapowanie może ponownie przetłumaczyć źródło, zanim zobaczy je usługa zdalna, i nie jest to domyślne zachowanie, które tylko routuje. Ponieważ trzeba je skonfigurować świadomie, traktuj je jako wyjątek projektowy, a nie coś, co dziedziczysz przypadkiem. Jeśli nikt w twoim zespole nie pamięta, że je włączono, zakładaj, że go nie ma, dopóki nie przeczytasz załącznika.

Jeśli twój projekt go używa, lista dozwolonych musi opisywać końcowe mapowanie, a nie adres bramy NAT. Ta sama ostrożność dotyczy ścieżek dostępności: gdy uczestniczy kilka adresów bram, oczekiwanym zbiorem źródeł jest suma, a nie jeden reprezentatywny adres. Zapisz, do którego tłumaczenia należy każdy adres, bo listy bez pochodzenia nie da się później zaudytować.

Prywatnej bramie NAT nie można dać usługi internetowej, wskazując ją na bramę internetową; AWS dokumentuje, że taki ruch jest odrzucany. Wybierz typ na podstawie całej ścieżki, a nie słowa VPN w wymaganiu.

Napisz umowę, na której twój partner może działać

Użyteczna umowa ma cztery części: kierunek, z którego inicjowane są przepływy, przetłumaczoną tożsamość, którą zobaczy partner, trasę powrotną dla tej tożsamości i obowiązujący zakres ochrony. Przepływy bramy NAT są inicjowane po obsługiwanej stronie źródłowej, więc nie jest to usługa przekierowania portów przychodzących do wystawiania prywatnego obciążenia. Powiedzenie tego głośno wcześnie zapobiega przeglądowi projektu, w którym każda strona zakładała, że zainicjowała druga.

Tłumaczenie kupuje ulgę w nakładaniu się adresów i przewidywalną politykę źródeł, a kosztuje indywidualną tożsamość obciążenia w logach partnera. Jeśli audyt wymaga przypisania na obciążenie, trzymaj tę tożsamość w warstwie aplikacji, zamiast próbować odtworzyć ją z przetłumaczonego adresu źródłowego.

Potem sprawdź ponownie obie tabele tras po każdej zmianie, bo nowy załącznik lub ponownie skojarzona podsieć po cichu przepisuje odpowiedź.