AWS VPN: lokalny i zdalny CIDR - która strona jest która?

Otwierasz opcje Site-to-Site VPN, widzisz dwa pola CIDR oznaczone jako lokalne i zdalne i sięgasz po adres, który uważasz za lokalny: VPC. To odwrotność tego, co ma na myśli API. W opcjach połączenia LocalIpv4NetworkCidr nazywa stronę bramy klienta, a RemoteIpv4NetworkCidr stronę AWS, ponieważ połączenie jest budowane od bramy klienta. Konsola nigdy nie mówi tego głośno i nic nie odrzuca wiarygodnie wyglądającej zamiany.

Zacznij od wywołania API, nie od etykiety w konsoli

Przeczytaj dokumentację opcji połączenia raz, do końca, i zauważ, że każda opcja jest napisana z punktu widzenia bramy klienta. To nie przypadkowość nazewnictwa. Tunel jest opisany tak, jak widzi go urządzenie kończące go po twojej stronie, więc lokalny oznacza sieć za twoją bramą, a zdalny sieć za bramą AWS. Zarówno pola IPv4, jak i IPv6 podlegają tej samej regule.

Zapisz obie etykiety na karteczce, zanim cokolwiek wpiszesz: strona klienta, strona AWS. Następnie przypisz do nich swoje adresy.

Prześledzony przykład z rolami

Załóżmy, że prefiks lokalny to 10.20.0.0/16, a prefiks VPC to 10.60.0.0/16. Opcje czytają się dokładnie tak, jak sugerują role, z zakresem lokalnym w polu lokalnym:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

Teraz przekaż tę samą parę osobie konfigurującej urządzenie partnerskie i zobacz, jak zastawka działa. W wielu zaporach lokalny oznacza interfejs, na którym kończy się tunel, a zdalny drugi koniec, co dla strony AWS jest odwrotnym mapowaniem. Obie osoby mogą mieć rację i mimo to stworzyć tunel, który nigdy nie wstanie, bo oba słowniki opisują różne punkty końcowe.

Powtórz ćwiczenie na papierze w terminologii partnera, z oboma CIDR i obiema etykietami, zanim dotkniesz jakiegokolwiek urządzenia.

Wartości domyślne nie są projektem

Ta sama dokumentacja podaje 0.0.0.0/0 jako wartość domyślną obu pól IPv4, z analogicznymi wartościami dla IPv6. Widok tych wartości w istniejącym połączeniu mówi, że pole nigdy nie zostało zawężone, a nie że skonfigurowano wyjście do internetu. Dystrybucja tras, tablica tras podsieci i mechanizmy bezpieczeństwa nadal decydują, jaki ruch może faktycznie przejść; wartości CIDR opisują tylko, jakie zakresy tunel jest gotów wybierać.

Zastąpienie węższej wartości domyślną nie jest więc trikiem zgodności, który stosuje się, gdy tunel zachowuje się źle. Poszerza selektor i pozostawia każdą inną warstwę dokładnie taką, jaka była.

Urządzenie partnerskie używa drugiego punktu widzenia

Gdy strona AWS jest jasna, konfiguracja partnera to miejsce, w którym mieszka większość pozostałego zamieszania. Urządzenie pytające o sieć lokalną i sieć zdalną opisuje własny interfejs jako lokalny, więc twój zakres VPC trafia do jego pola zdalnego, a zakres lokalny do pola lokalnego. Jeśli zamiast tego pyta o selektory ruchu parami, zapisujesz oba kierunki jawnie i etykiety mają mniejsze znaczenie niż parowanie.

Czytaj pomoc pól urządzenia, a nie nazwy jego pól. Producenci używają tych samych dwóch słów na trzy różne pojęcia.

Potem sprawdź stan tunelu dla obu faz, bo niedopasowany selektor zwykle objawia się jako awaria drugiej fazy, podczas gdy pierwsza faza stoi spokojnie ustanowiona.

Zmieniaj opcje jak zmianę, nie jak dokumentację

Edycja opcji połączenia na działającym VPN może przerwać usługę, więc traktuj to jako czynność serwisową z oknem, wartością powrotu i notatką, kogo dotyczy. Najpierw zapisz bieżące opcje, w tym oba pola CIDR i opcje tunelu, aby powrót był wklejeniem, a nie odtworzeniem.

Po zmianie sprawdź ze strony AWS i od partnera: źródło w każdym zakresie dociera do celu w drugim, w obu kierunkach. Jeden ping z jednej strony dowodzi jednego selektora.

Następnie zaktualizuj dokumentację połączenia, wypisując role, aby następna osoba nie musiała odkrywać na nowo, że lokalny oznacza twoją stronę.