EC2 w strefach dostępności: sprawdź routing przed VPN

Zanim zainstalujesz oprogramowanie VPN między dwiema instancjami EC2, odpowiedz na jedno pytanie: czy są w tym samym VPC? Jeśli tak, prywatna ścieżka już istnieje, a umieszczenie w różnych strefach tego nie zmienia. Większość pracy w tej sytuacji polega na potwierdzeniu, której tabeli routingu faktycznie używa każda podsieć, a następnie na ustaleniu, czy awaria w ogóle była problemem routingu. Tunel jest zwykle złą odpowiedzią na to konkretne pytanie.

Sprawdzenie 1: ten sam VPC czy różne VPC

VPC jest regionalny i obejmuje strefy dostępności, natomiast każda podsieć należy do dokładnie jednej strefy. Dwie instancje w różnych strefach jednego VPC nadal znajdują się w tej samej domenie prywatnego routingu.

Różne VPC nigdy nie otrzymują prywatnej trasy tylko dlatego, że współdzielą region lub etykietę strefy. Taki przypadek wymaga obsługiwanego połączenia oraz własnej pracy nad trasami i uprawnieniami, co jest osobną decyzją.

Sprawdzenie 2: co mówią tabele tras podsieci

Zapisz układ z rzeczywistymi wartościami. VPC pod adresem 10.60.0.0/16 z podsieciami 10.60.1.0/24 i 10.60.2.0/24 daje instancjom 10.60.1.10 i 10.60.2.20 ścieżkę przez lokalną trasę VPC.

Następnie przejrzyj tabele powiązane z obiema podsieciami, a nie tylko tę, którą znalazłeś pierwszą. Bardziej szczegółowa trasa inspekcji lub urządzenia może zastąpić trasę bazową, a cel trasy lokalnej sam może zostać zastąpiony w nowszych konfiguracjach. Widoczna gdzieś w konsoli trasa lokalna nie dowodzi, że używają jej oba obciążenia.

Używaj prywatnych adresów i nazw, które VPC rzeczywiście przydziela. Prywatny adres nie musi zaczynać się od 10, a wymyślanie go z pamięci to sposób na błędną diagnozę działającego środowiska.

Sprawdzenie 3: routing czy autoryzacja

Routing tylko doprowadza pakiet do interfejsu sieciowego celu. Grupa zabezpieczeń celu nadal musi dopuścić źródło i usługę, reguły wyjścia źródła muszą zezwalać na żądanie, a każda sieciowa ACL musi zezwalać na oba kierunki, ponieważ ACL nie przechowują stanu.

Za tym stoją zapora gościa, powiązanie nasłuchu i tożsamość samej aplikacji. Każde z nich może odrzucić żądanie, które routing dostarczył bezbłędnie.

Akceptacja musi być rzeczywistą operacją aplikacji. Udany ping nie daje dostępu do aplikacji ani nie dowodzi, że nazwa TLS i poświadczenia są poprawne, a zablokowany ping nie dowodzi, że wszystkie prywatne usługi są niedostępne.

Sprawdzenie 4: czy osobne połączenie jest naprawdę potrzebne

VPN nadal może należeć do projektu, ale z podanego powodu: połączyć ten VPC z biurem, dopuścić laptopy lub spełnić wymóg warstwy nakładki. Ten powód różni się od zwykłej komunikacji w obrębie tego samego VPC.

Pamiętaj też, czym VPC nie jest. Nie jest rozszerzeniem domowego segmentu Ethernet. Aplikacja, która opiera się na wykrywaniu rozgłoszeniowym, ma osobny wymóg do oceny. To luka w projekcie, a nie błąd routingu.

Sprawdzenie 5: kwestia szyfrowania

Prywatny adres i reguła zezwolenia nie mówią nic o ochronie kryptograficznej w warstwie aplikacji. Jeśli dane wymagają ochrony od końca do końca, pochodzi ona z protokołu i modelu tożsamości, które usługa rzeczywiście obsługuje.

W notatce projektowej trzymaj twierdzenia o warstwie sieciowej i aplikacyjnej osobno, ponieważ ich łączenie to sposób, w jaki przegląd kończy się twierdzeniem o ochronie, której nikt nie wdrożył.

Co zapisać

Zapisz oba identyfikatory podsieci, tabelę tras powiązaną z każdą z nich, odwołania do grup zabezpieczeń i operację aplikacji, którą przetestowałeś. To cztery fakty i rozstrzygają one większość przyszłych sporów o tę ścieżkę.

Samo umieszczenie w strefie nigdy nie mówi, że należy dodać VPN, i nigdy nie wyjaśnia, dlaczego prywatne żądanie nie powiodło się.