VGW czy TGW? Gdzie kończy się tunel IPsec AWS Site-to-Site

Ludzie pytają, gdzie AWS Site-to-Site VPN przestaje chronić pakiet, i oczekują jednej odpowiedzi: na bramie. Użyteczna wersja tej odpowiedzi nazywa, która brama, bo wirtualna brama prywatna i brama tranzytowa to różne układy z różnymi obiektami załączników, a recenzent, który założy niewłaściwy, buduje resztę oceny na diagramie, którego nie ma. Wykonaj trzy poniższe kontrole po kolei. Każda albo potwierdza granicę, albo mówi, że poprzednia odpowiedź dotyczyła innego zasobu.

Nazwij trzy punkty końcowe, zanim cokolwiek ocenisz

Przegląd szyfrowania tej ścieżki wymaga trzech nazwanych rzeczy: bramy klienta, celu AWS VPN, który kończy IPsec, oraz punktu końcowego aplikacji, który odbiera pakiet wewnętrzny. Zapisz je wraz z identyfikatorami zasobów, zanim otworzysz choć jedną stronę konsoli, bo wszystko po tym punkcie jest twierdzeniem o jednym z tych trzech.

Brama klienta jest Twoja, a jej konfiguracja jest dla Ciebie widoczna. Cel AWS jest zasobem zarządzanym, a błąd polega na założeniu go: połączenie VPN może podłączyć się do wirtualnej bramy prywatnej lub bezpośrednio do bramy tranzytowej i żadne nie implikuje drugiego. Trzeci punkt końcowy to ten, który ludzie pomijają, i tylko on odpowiada na rzeczywiste pytanie o dane aplikacji.

Kontrola 1: która brama faktycznie kończy tunel

Oba układy są obsługiwane i przewodnik po architekturze Site-to-Site VPN opisuje je obok siebie, więc pytaj API, a nie diagramu, który często ma rok. Zapytanie tylko do odczytu na jednym połączeniu zwraca pola celu VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Wyróżnikiem jest TransitGatewayId, a nie VpnGatewayId. Połączenie z pustym TransitGatewayId kończy się na samodzielnej wirtualnej bramie prywatnej, a połączenie z ustawionym tym polem kończy się na załączniku VPN bramy tranzytowej, i VpnGatewayId może w tym przypadku nadal być wypełnione, bo może nazywać bramę nośną załącznika. Najpierw przeczytaj pole TGW, potem potwierdź typ załącznika z listy załączników, a nie z nazwy pola, bo załącznik VPC na tej bramie tranzytowej nie jest załącznikiem VPN. Znalezienie instancji docelowej w podłączonym VPC nic nie mówi o tym, który załącznik VPN przeniósł pakiet.

Skoro tam jesteś, sprawdź tunele. Połączenie niesie dwa tunele IPsec dla nadmiarowości, a połączenie, którego drugi tunel nigdy się nie podniósł, jest realnym ustaleniem dla dostępności, choć nie zmienia niczego na granicy szyfrowania:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Kontrola 2: co pakiet wewnętrzny nadal niesie

Gdy IPsec się kończy, AWS przekazuje odszyfrowany pakiet trasą, która do niego pasowała. Od tego punktu ruch jest zwykłym ruchem VPC, a ochrona VPN się skończyła. To nie luka w usłudze; to właśnie znaczy granica, a punktem listy kontrolnej jest powiedzenie tego wprost, zamiast pozwolić, by "VPN jest szyfrowany" zastępowało "dane są szyfrowane od końca do końca".

Teraz zbadaj, co było w środku. Jeśli pakiet wewnętrzny to protokół aplikacji w postaci czystego tekstu, nic poniżej nie dodaje poufności, dopóki coś innego go nie zaszyfruje. Jeśli pakiet wewnętrzny już niesie sesję TLS, usunięcie zewnętrznego IPsec nic nie zmienia dla tej sesji: pozostaje chroniona aż do własnego punktu końcowego, gdziekolwiek ten punkt jest.

Częstą nadmierną korektą jest wniosek, że wszystko za bramą jest odsłonięte. Nie jest. Transport usługi, szyfrowanie magazynu i TLS aplikacji to odrębne mechanizmy z odrębnymi warunkami, a każdy trzeba ocenić na jego własnych warunkach, a nie wywnioskować z kształtu VPN. Wpis w dzienniku przepływu pokazujący ACCEPT dowodzi, że trasowanie działało, i nic nie mówi o poufności, co jest dokładnie tym błędem, któremu ta lista ma zapobiegać.

Kontrola 3: co kończy TLS za bramą

Idź za odbiorcą, nie za adresem. Jeśli równoważnik obciążenia lub proxy kończy TLS, połączenie trzymane przez Twojego klienta kończy się tam, a proxy otwiera drugie połączenie do backendu, które może być czystym tekstem lub TLS z innym łańcuchem zaufania. Prywatny adres IP i pasująca trasa nie są dowodem w sprawie tego drugiego połączenia.

Przetestuj punkt końcowy, na którym naprawdę Ci zależy, od wewnątrz VPC, z nazwą używaną przez aplikację, a nie z adresem IP, który raz rozwiązałeś:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Powtórz to dla każdego przeskoku, przez który przechodzi żądanie. Jeśli odpowiedź różni się między nazwą zwróconą do klienta a nazwą backendu, znalazłeś dokładnie ten segment, którego VPN nigdy nie objął, i to jest ustalenie, które trzeba zapisać.

Zapisz wynik jako segmenty, a nie jako werdykt

Wynikiem tej listy jest mała tabela z jednym wierszem na segment: brama klienta do celu AWS VPN, brama do obciążenia roboczego, obciążenie do magazynu danych i każdy przeskok proxy pomiędzy. Każdy wiersz mówi, co go chroni i od czego ta ochrona zależy. "Zaszyfrowane" bez mechanizmu i bez punktu końcowego nie jest wierszem.

Potem odpowiedz na pierwotne wymaganie tymi samymi słowami, w jakich je postawiono. Jeśli wymaganiem jest, by dane pozostawały poufne, dopóki obciążenie ich nie odbierze, VPN spełnia tylko pierwszy segment, a pozostałe wiersze wymagają transportu aplikacji, TLS usługi lub szyfrowania magazynu skonfigurowanych i zweryfikowanych osobno.

Zachowaj identyfikatory połączeń, stany tuneli i podmioty certyfikatów w zapisie. Gdy ktoś wróci do projektu po pół roku, te trzy artefakty odpowiadają na pytanie o granicę w kilka minut, zamiast zaczynać spór od nowa od diagramu.