Czy warto włączyć dzienniki tunelu AWS VPN na aktywnym tunelu?

Włączenie dzienników aktywności tunelu dla VPN typu Site-to-Site to niewielka zmiana, która może przewrócić tunel, który mierzy. AWS ostrzega, że włączenie rejestrowania na istniejącym tunelu może przerwać go na kilka minut, więc ciekawe pytanie nie brzmi, jak przełączyć flagę, ale na którym tunelu i kiedy to zrobić. Kolejność rozstrzygają trzy warunki: czy drugi tunel naprawdę przenosi trasy, czy potrzebujesz zdarzeń usługi czy zdarzeń BGP, oraz czy zmiana przechodzi przez konsolę czy przez API opcji tunelu. Pomylisz je i skończysz albo z przerwą, albo z grupą dzienników pełną niczego.

Kolejność rozstrzygają trzy warunki

Zacznij od tożsamości rzeczy, którą zmieniasz. Potrzebujesz identyfikatora połączenia VPN, regionu i zewnętrznego adresu IP konkretnego tunelu, ponieważ każde ustawienie dziennika w tej funkcji dotyczy tunelu, a nie połączenia. Zmiana zastosowana do niewłaściwego adresu zewnętrznego jest zmianą na tunelu, którego nikt nie debugował.

Miejscem docelowym jest grupa dzienników CloudWatch w tym samym regionie, z polityką przechowywania i dostępu, której naprawdę chcesz. AWS zaleca prefiks /aws/vendedlogs/ dla tych grup, ponieważ pozwala uniknąć limitów rozmiaru polityki zasobów, na które mogą trafić zwykłe nazwy. Nazwa taka jak /aws/vendedlogs/vpn/branch-a-activity jest tylko przykładem; liczy się to, że grupa istnieje, że rola dostarczania może do niej pisać i że obie są zarządzane przez właściciela konfiguracji VPN. Nazwa nie przyznaje uprawnień, a grupa utworzona bez polityki dostarczania daje ciszę zamiast błędu.

Warunek pierwszy: zapasowy tunel, który naprawdę przenosi ruch

To warunek, który zespoły pomijają. Dwa skonfigurowane tunele nie są dowodem, że aplikacja ma użyteczną trasę alternatywną.

Zanim dotkniesz jednego tunelu, potwierdź, że drugi przenosi ważne trasy: sprawdź tablicę routingu po stronie bramy klienta i potwierdź, że aplikacja naprawdę może przełączyć się awaryjnie. Okno przerwy w AWS liczy się w minutach, nie w sekundach, a tunel istniejący tylko na papierze zamienia zmianę diagnostyczną w awarię. Jeśli trasa zapasowa nie jest udowodniona, zaplanuj zmianę z taką samą troską jak każdą inną zmianę routingu, zamiast traktować rejestrowanie jako bierne. Instrumentuj tunel, którego zachowanie próbujesz wyjaśnić, a nie ten, do którego łatwiej dotrzeć.

Warunek drugi: dziennik aktywności czy dziennik BGP

Ten warunek decyduje, co naprawdę będziesz mógł przeczytać. Rekordy aktywności obejmują zdarzenia usługi, takie jak przejścia stanu IKE i IPsec oraz komunikaty DPD, czego chcesz, gdy tunel nie wstaje albo stale odnawia klucze. Rekordy BGP to osobny strumień z własnymi mechanizmami kontroli i odpowiadają na inne pytanie: czy trasy zostały wymienione i wycofane zgodnie z oczekiwaniami.

Włączenie flagi aktywności nie jest prośbą o każdy strumień, który usługa może emitować. Jeśli podejrzenie dotyczy routingu, włącz oba; jeśli podejrzenie dotyczy negocjacji fazy 1 lub fazy 2, strumień aktywności to pokaże.

Żaden z tych strumieni nie jest przechwytywaniem pakietów i ta różnica rozstrzyga więcej zgłoszeń, niż powinna. Rekordy aktywności i BGP mówią, co usługa zrobiła z tunelem i sesją, a nie co twoja aplikacja przez nie wysłała. Sięganie po dzienniki tunelu, by debugować limit czasu aplikacji, to błąd kategorii i zwykle kosztuje jedno okno przerwy, zanim ktoś to zauważy. Najpierw wybierz pytanie, potem strumień, który może na nie odpowiedzieć.

Warunek trzeci: zmiana przez konsolę czy API opcji tunelu

Jeśli człowiek robi jednorazową zmianę, ścieżka przez konsolę jest w porządku: VPC console, Site-to-Site VPN connections, wybierz połączenie, Actions, Modify VPN tunnel options, wybierz zewnętrzny IP, włącz Tunnel activity log, wybierz grupę i format wyjściowy, zapisz w oknie. Jeśli VPN jest zarządzany jako kod, to samo kliknięcie jest dryfem, który później uzgodnisz.

W automatyzacji część opcji tunelu dotycząca dziennika aktywności ma stały kształt: LogOptions zawiera CloudWatchLogOptions z LogEnabled, LogGroupArn i LogOutputFormat. Ten blok jest fragmentem, nie żądaniem; modify-vpn-tunnel-options nadal potrzebuje identyfikatora połączenia i zewnętrznego IP tunelu, a pozostałe ustawienia tunelu musi zachować właściciel szablonu. Rejestrowanie BGP używa własnych kluczy BgpLogEnabled, BgpLogGroupArn i BgpLogOutputFormat w tej samej strukturze. Odczytaj zmianę z powrotem za pomocą describe-vpn-connections, zamiast ufać, że wywołanie zostało zastosowane.

Co rekordy mogą, a czego nie mogą ci powiedzieć

Gdy pierwszy tunel jest gotowy, a zamierzona ścieżka dostępna, powtórz tę samą kontrolowaną sekwencję dla drugiego tunelu, jeśli też potrzebujesz jego dzienników. Jeden tunel naraz to cała istota.

Rekordy przychodzą w strumieniach identyfikowanych przez połączenie i zewnętrzny adres tunelu, więc koreluj z tą tożsamością, zamiast oczekiwać, że historia pojawi się wstecznie. Nic przed zmianą nie istnieje i żadne czekanie nie wypełni tej luki. Jeśli potrzebujesz linii bazowej, zapisz bieżący stan tunelu i tablicę routingu przed zmianą, żeby było z czym porównać.

Trzymaj grupę dzienników, jej przechowywanie, uprawnienia dostarczania i blok opcji tunelu w tym samym spisie co sam VPN, bo to jedna konfiguracja rozłożona na cztery miejsca. Procedura AWS włączania dzienników opisuje przepływ pracy dla każdego tunelu i jego ostrzeżenie o przerwie, i warto ją przeczytać przed zmianą, a nie po niej. Potem sprawdź po kolei: tunel wrócił, rekordy pojawiają się w oczekiwanym strumieniu, a rekordy odpowiadają na pytanie, dla którego otworzyłeś zgłoszenie. Jeśli trzeci punkt zawiedzie, problemem był wybór strumienia, a nie rejestrowanie.