Pełny tunel Access Server na EC2: dlaczego jedno pole wyboru nie wystarcza

Wyłączenie sprawdzania źródła i celu na instancji EC2 to najczęściej powtarzana odpowiedź na pytania o wyjście do internetu w Access Server i samo w sobie nie robi nic dla Twoich klientów. Sprawdzanie jest ograniczeniem przekazywania w AWS: pozwala instancji przyjmować pakiety, których źródło lub cel nie jest jej własnym adresem. Nie mówi klientowi Access Server, aby wysyłał ruch internetowy przez tunel, nie tworzy trasy w górę i nie dodaje NAT. Mit polega na tym, że pole wyboru jest funkcją.

Co sprawdzanie naprawdę kontroluje

Każdy interfejs sieciowy EC2 odrzuca ruch, który nie jest do niego adresowany, chyba że instancja działa jako router, urządzenie NAT lub brama VPN, a Ty wyłączysz to sprawdzanie. Wyłączenie daje pozwolenie na przekazywanie. Pozwolenie nie jest konfiguracją: instancja nadal potrzebuje trasy do bramy internetowej lub urządzenia NAT, tabela tras VPC nadal potrzebuje odpowiedniego wpisu, grupy bezpieczeństwa nadal muszą dopuszczać przepływ, a serwer nadal musi tłumaczyć lub trasować ruch powrotny.

Sprawdź bieżącą wartość za pomocą aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck, zanim cokolwiek zmienisz. Jeśli zmieniasz ją w konsoli, zmień ją dlatego, że instancja przekazuje za innych, a nie dlatego, że klient nie dociera do internetu.

Polityka trasowania klienta należy do Access Server

W Access Server 3 otwórz Access Controls i znajdź sekcję Internet Access and DNS. Wybór Internet Gateway oferuje pełny lub dzielony tunel; pełny tunel każe klientowi kierować ruch domyślny do VPN, dzielony pozostawia ruch internetowy na lokalnej ścieżce klienta. Zapisz i zastosuj przez przepływ pracy produktu, a następnie ponownie połącz klienta testowego, ponieważ polityka jest dostarczana w momencie połączenia.

Starsze wersje używają innych menu, a niektóre kompilacje Community OpenVPN nie mają równoważnej kontroli. Sprawdź zainstalowaną wersję główną, zanim zaczniesz szukać ekranu, którego nie ma. Następnie potwierdź, co otrzymał klient: profil pełnego tunelu powinien instalować trasę domyślną przez tunel, a profil dzielonego tunelu nie powinien.

Prześledź pakiet po tunelu

Gdy klient wyśle ruch internetowy do tunelu, serwer musi go przekazać i zwykle przetłumaczyć. Access Server zarządza własnymi regułami NAT i trasowania, więc czytaj faktyczną konfigurację, zamiast dopisywać reguły Community OpenVPN do generowanych plików; niezarządzane reguły są nadpisywane lub kolidują przy następnej aktualizacji produktu. sudo iptables -t nat -L -n -v lub odpowiednik nftables pokazuje, co naprawdę jest tłumaczone.

Strona AWS to osobna ścieżka. Instancja w podsieci publicznej dociera do bramy internetowej bezpośrednio i zachowuje swój adres publiczny lub elastyczny IP. Instancja w podsieci prywatnej potrzebuje trasy do bramy NAT lub instancji NAT, a urządzenie NAT potrzebuje własnej trasy do bramy internetowej. Podłączenie bramy internetowej do VPC samo w sobie nie daje żadnemu źródłu prywatnemu publicznego adresu powrotnego, dlatego ta sama konfiguracja Access Server działa w jednej podsieci, a w innej po cichu zawodzi.

Sprawdź tabelę tras powiązaną z podsiecią instancji, nie tylko główną tabelę VPC. Powiązania podsieci mają pierwszeństwo przed tabelą główną, a nieaktualne powiązanie to częsta przyczyna zatrzymania działającej konfiguracji po przebudowie.

Trzymaj wyjście IP i DNS osobno

Przetestuj najpierw literal adresu, potem nazwę, z tej samej aplikacji klienta. Jeśli curl -4 https://checkip.amazonaws.com zwraca adres publiczny, ale nazwy hostów zawodzą, tunel i ścieżka NAT działają, a problemem jest DNS: wysłany resolver, stan resolvera klienta lub grupa bezpieczeństwa blokująca resolver. Ustawienia DNS Access Server znajdują się w tym samym obszarze Internet Access, ale podróżują inną ścieżką kodu.

Porównaj zwrócony adres z zamierzonym wyjściem. Jeśli to publiczny adres instancji, ruch jest tłumaczony przez instancję; jeśli to adres bramy NAT, używana jest ścieżka podsieci prywatnej. Oba mogą być poprawne. Nie możesz jednak wywnioskować, że przeglądarka na serwerze dowodzi przekazywania dla klienta.

Nie pozwól, by jedno pole zamknęło dochodzenie

IPv6 to osobna decyzja. Polityka pełnego tunelu dla IPv4 nie mówi nic o tym, czy IPv6 jest przenoszony, blokowany czy wycieka, a klient z dwoma stosami może nadal korzystać z lokalnej ścieżki IPv6, podczas gdy IPv4 idzie przez tunel. Przetestuj rodzinę adresów, na której naprawdę Ci zależy, i wyraźnie zdecyduj, czy drugą należy wyłączyć.

Na koniec przetestuj stan rozłączony. Wybór pełnego tunelu opisuje politykę trasowania podczas połączenia, a nie to, co się dzieje, gdy tunel padnie. Jeśli wymaganiem jest, aby żaden ruch nie wydostał się poza VPN, to pytanie o kill-switch i zaporę ogniową, i wymaga własnego testu, a nie wniosku z tabeli tras.