Dlaczego GRE i ESP nie działają przez bramę NAT w AWS

Tunel nie działa, grupa zabezpieczeń już zezwala na cały ruch, a wniosek jest taki, że AWS blokuje VPN. Nic nie blokuje. Zarządzana brama NAT przekazuje udokumentowany zestaw protokołów zewnętrznych, a natywne GRE ani natywne ESP nie należą do niego, więc żadna dodana reguła nie sprawi, że brama je przeniesie. Reguła zezwolenia i zdolność transportu to dwie różne rzeczy, a zmienić można tylko jedną z nich.

Zestaw reguł nie jest zestawem protokołów

Grupa zabezpieczeń decyduje, który ruch może opuścić instancję. Brama NAT decyduje, co może przetłumaczyć i przekazać. Gdy działa drugie ograniczenie, reguła zezwalająca daje dokładnie ten objaw, który ludzie błędnie odczytują jako problem zapory: pakiety opuszczają instancję, wymiana kontrolna może nawet się zakończyć, a do partnera nic nie dociera.

Specyfikacja protokołów bramy NAT od AWS wymienia TCP, UDP i ICMP dla usługi zarządzanej. To cały obsługiwany zestaw. Reguła zezwolenia dla innego protokołu IP nie może go rozszerzyć, ponieważ reguła jest oceniana znacznie wcześniej, niż zostanie osiągnięta ścieżka przekazywania bramy.

To rozróżnienie ma znaczenie, ponieważ oba błędy wyglądają z perspektywy klienta identycznie i mają zupełnie różne poprawki.

PPTP pokazuje, dlaczego test portu kłamie

PPTP to najjaśniejszy stary przykład sprawdzenia portu, które niczego nie dowodzi. Otwiera połączenie kontrolne TCP na porcie 1723, a następnie przenosi dane tunelu przez GRE, czyli protokół IP 47. Protokół 47 to nie port TCP 47, a te dwie liczby nie mają ze sobą nic wspólnego poza dzieleniem cyfr.

Operator, który testuje łączność z 1723 i widzi ukończone uzgadnianie, wnioskuje, że ścieżka działa. Potem kanał danych nigdy nie przepuszcza ani jednego pakietu, ponieważ brama nie ma żadnego wsparcia GRE do zaoferowania. To interpretacja wymagań starego protokołu, a nie rada, by wdrażać PPTP, który jest przestarzały od lat.

To samo rozumowanie dotyczy każdego protokołu, którego kanał kontrolny to TCP lub UDP, podczas gdy jego ścieżka danych nie.

IPsec przetrwa tylko jako UDP

IPsec to przypadek, w którym odpowiedź jest warunkowa, a nie stanowczo nie. AWS dokumentuje NAT traversal jako obsługiwany układ dla IPsec przez bramę NAT. Po wynegocjowaniu NAT-T ESP jest kapsułkowany w UDP, a brama widzi zwykły UDP zamiast protokołu 50.

Zezwolenie na UDP 4500 nie sprawia, że punkty końcowe używają NAT traversal. Zezwala na pakiety tylko wtedy, gdy są już tak ukształtowane. Potwierdź w wyjściu negocjacji samego klienta, które kapsułkowanie zostało wybrane, i potwierdź po stronie odbierającej, że partner je zaakceptował. Dwa punkty końcowe skonfigurowane dla natywnego ESP będą nadal wysyłać natywne ESP, cokolwiek mówi zestaw reguł.

VPN oparty na TCP lub UDP pasuje do udokumentowanego zestawu transportów i mimo to może zawieść z powodu routingu, filtrowania lub uwierzytelniania. Pasowanie do zestawu jest konieczne, nie wystarczające.

Sprawdź ścieżkę, zanim rozszerzysz politykę

Zweryfikuj rzeczywistą trasę podsieci obciążenia i tożsamość jej następnego skoku najpierw. Bezpośrednia ścieżka publiczna, instancja NAT, zarządzana brama NAT i ścieżka prywatna przez bramę tranzytową to cztery różne projekty, a tylko jeden z nich jest opisywaną tutaj usługą zarządzaną.

Następnie zapisz wypróbowany punkt końcowy, rodzinę adresów, protokół zewnętrzny i port, jeśli protokół go ma. Użyj diagnostyki klienta i obserwacji przepływu właściciela sieci zamiast udanego żądania przeglądarki, które dowodzi tylko, że TCP i UDP działają. Po tym przejrzyj grupę zabezpieczeń, ACL podsieci, zaporę gościa i politykę usługi dla obu kierunków przepływu.

Nie otwieraj całego ruchu, aby zrekompensować transport, którego usługa nie może przenieść. Zmiana reguły tego nie naprawi i przetrwa incydent.

Gdy transport nie pasuje

Jeśli protokół zewnętrzny jest poza obsługiwanym zestawem, poprawka jest architektoniczna: wybierz transport, który ścieżka może przenieść, lub przenieś wyjście na coś, co przenosi potrzebny. OpenVPN przez UDP, WireGuard przez UDP i tunele oparte na TLS pasują do udokumentowanego zestawu. Instancja NAT zarządzana przez klienta jest opcją, gdy konkretny protokół musi przejść, a koszt operacyjny jego utrzymania jest akceptowalny.

Hostowanie przychodzącego serwera VPN to osobny problem z osobną odpowiedzią. Brama NAT zapewnia tłumaczenie wyjściowe i nie zapewnia ogólnego przekierowania portów przychodzących, więc serwer za nią potrzebuje zatwierdzonego wejścia publicznego zaprojektowanego na własnych warunkach.

Kolejność pracy: nazwij protokół zewnętrzny, potwierdź następny skok, porównaj go z udokumentowanym zestawem, a następnie zmień architekturę lub transport. Inny numer portu nie zamieni GRE na TCP, a jeszcze jedna reguła zezwalająca nie zamieni ukończonej wymiany kontrolnej w działający kanał danych.