Elastic IP w EC2 nie jest prywatnym adresem VPN instancji

Instancja ma prywatny adres, Elastic IP jest z nim powiązany, a trasa dla tego publicznego /32 jest dodawana do VPN w nadziei, że oba staną się tym samym. Nie stają się. Elastic IP to translacja wykonywana poza gościem, przez bramę internetową, na ruchu, który podąża ścieżką internetową. System operacyjny gościa nigdy nie widzi tego adresu skonfigurowanego na interfejsie. Dodanie go do interfejsu tunelu nie odtwarza translacji powyżej i tworzy drugą, sprzeczną tożsamość dla tej samej maszyny.

Dwa adresy, jedna instancja

Interfejs sieciowy instancji ma prywatny adres wewnątrz VPC i to jest adres, który zna gość. Elastic IP jest powiązany z tym samym interfejsem, ale żyje po publicznej stronie mapowania.

Wszystko, co dociera do instancji przez internet, przychodzi przetłumaczone na prywatny adres. Wszystko, co instancja wysyła do internetu, wychodzi z Elastic IP jako źródłem, ponownie z powodu tej translacji.

Wewnątrz gościa istnieje jeden adres. Na zewnątrz istnieją dwa. Ta asymetria wyjaśnia większość zamieszania w tej dziedzinie. Gość nie może skonfigurować tego, co tłumaczy brama. Może odpowiadać tylko na adresie, który faktycznie posiada.

Co faktycznie robi brama internetowa

Dokumentacja AWS dotycząca bramy internetowej opisuje układ: instancja zna swój prywatny adres IPv4, a brama zapewnia odpowiednią translację na publiczny IPv4 lub Elastic IP dla ruchu na ścieżce internetowej.

To translacja adresów sieciowych, nie alias. Mapowanie jest utrzymywane przez bramę, powiązane z asocjacją i dotyczy tylko pakietów, które przez nią przechodzą. Usuń asocjację, a publiczna tożsamość znika, zanim gość cokolwiek zauważy.

Dlatego prywatny pakiet VPN zaadresowany do publicznego /32 nie jest reinterpretowany jako prywatny pakiet do lokalnego adresu gościa. Pakiet podąża za trasą, do której pasuje, a ta wysyła go do bramy internetowej; zachowanie bramy zależy od tego, czy ścieżka jest dozwolona w obu kierunkach.

Dlaczego sztuczka z interfejsem tunelu zawodzi

Przypisanie Elastic IP do interfejsu tunelu wymaga od gościa traktowania adresu publicznego jako lokalnego. Teraz dwie rzeczy roszczą sobie ten sam adres: translacja bramy na ścieżce internetowej i lokalny interfejs wewnątrz tunelu. Ruch powrotny nie ma spójnej odpowiedzi, który z nich obowiązuje.

Nawet gdy wydaje się to działać, projekt ukrył prawdziwe pytanie. Klienci docierają albo do prywatnego adresu przez tunel, albo do publicznego punktu końcowego przez internet, a obie ścieżki mają inne grupy zabezpieczeń, inne logowanie i inne tryby awarii.

Adres nigdy nie był problemem. Wybór ścieżki był.

Trzy cele, trzy projekty

Jeśli celem jest publiczny punkt końcowy VPN, Elastic IP jest właściwym narzędziem: zdalni partnerzy łączą się z nim przez internet, a szyfrowany transport kończy się na instancji. Wewnętrzny ruch aplikacji korzysta wtedy z prywatnego adresu.

Jeśli celem jest prywatny dostęp do aplikacji, miejscem docelowym jest prywatny adres lub prywatna nazwa DNS, która się na niego rozwiązuje, a trasa VPN, grupa zabezpieczeń i ścieżka powrotna muszą się zgadzać. Elastic IP w ogóle nie występuje w tym projekcie.

Jeśli celem jest stabilna publiczna tożsamość wyjściowa dla użytkowników VPN, to projekt NAT po stronie wyjścia, a nie adres w tunelu klienta. Trzy podobnie brzmiące cele dają trzy różne diagramy, a tylko jeden z nich polega na umieszczeniu Elastic IP w nowym miejscu.

Sprawdź wybraną ścieżkę

Dla dostępu prywatnego potwierdź, że trasa VPN obejmuje prywatny prefiks, tabela tras VPC zwraca ruch do tunelu, grupa zabezpieczeń zezwala na źródło klienta, a zapora klienta zezwala na odpowiedź. Następnie przetestuj jedno rzeczywiste żądanie zamiast ping.

Dla dostępu publicznego potwierdź wyjście internetowe klienta, routing publicznego wejścia i jego politykę bezpieczeństwa. To, czy klient VPN może dotrzeć do publicznego punktu końcowego przez tunel, zależy od reguł wyjścia i zapory tunelu, a nie od asocjacji Elastic IP.

Jeśli publiczna nazwa hosta ma działać z obu stron, użyj projektu DNS, który odpowiada prywatnym adresem klientom VPN, a publicznym wszystkim innym, i utrzymuj certyfikat ważny dla nazwy, a nie dla adresu. Kolejność pracy: nazwij cel, wybierz należący do niego adres, a potem zweryfikuj trasy, politykę i jedno żądanie.