Rotacja PSK w AWS VPN: który tunel pada i kiedy

Zmiana jednego wstępnie współdzielonego klucza tunelu AWS VPN wyłącza ten tunel, dopóki obie strony się nie zgodzą. Najpierw udowodnij ścieżkę zapasową, a potem rotuj tunele pojedynczo.

Tunel pada w momencie, gdy oba końce nie zgadzają się co do wstępnie współdzielonego klucza, i pozostaje wyłączony, dopóki obie strony nie będą miały nowej wartości. Ta część jest oczekiwana: AWS traktuje zmianę jako przerwę w wybranym tunelu, a partner nie ukończy IKE, dopóki klucze się różnią. To, co zaskakuje ludzi, to druga połowa. Drugi tunel nie przejmuje ruchu sam z siebie, chyba że sprawdzono, że potrafi go unieść. Rotuj w tej kolejności, a przerwa pozostanie w obrębie jednego tunelu.

Co faktycznie dzieje się, gdy klucz się zmienia

ModifyVpnTunnelOptions przepisuje opcje jednego tunelu, identyfikowanego po jego zewnętrznym adresie IP. Tunel jest rozbierany i budowany od nowa, więc IKE i IPsec negocjują od zera z nowym kluczem. AWS podaje, że przerwa może trwać kilka minut, co wystarcza, by protokół routingu to zauważył. Drugi tunel w tym samym połączeniu nie jest naruszany przez to wywołanie.

Jest jeszcze drugi efekt, o którym warto wiedzieć przed wysłaniem czegokolwiek. Operacja zmiany przyjmuje cały zestaw opcji tunelu, więc pominięte pole zostaje zapisane z powrotem z wartością domyślną. Jeśli dostrajałeś czasy życia fazy 1 lub fazy 2 albo ustawienia wykrywania martwego partnera, przekaż bieżące wartości w tym samym żądaniu albo zaplanuj ich przywrócenie później.

Najpierw odczytaj bieżące wartości, a potem zmień jedno pole. Ta kolejność to cała dyscyplina tego zadania.

Najpierw dopasuj tunel AWS do właściwego partnera

Konsola etykietuje tunele według kolejności, a Twoje urządzenie nie używa tej etykiety. Zidentyfikuj tunel po jego zewnętrznym adresie IP i dopasuj go do sekcji partnera na bramie klienta. Tunel 1 w konfiguracji lokalnej nie jest dowodem, że edytujesz tunel, który AWS nazywa tunelem 1.

Zacznij od samego połączenia, które wymienia oba tunele i klucz, który każdy z nich obecnie trzyma:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

Zwrócony klucz to ten używany teraz. Porównaj go z konfiguracją partnera, zanim cokolwiek zmienisz, bo już istniejąca niezgodność wyjaśnia tunel, który nigdy nie był stabilny.

Najpierw pozwól drugiemu tunelowi nieść ruch

Dwa tunele w jednym połączeniu nie dowodzą, że Twoje urządzenie skonfigurowało oba, że oba ogłaszają potrzebne prefiksy albo że ruch przemieszcza się między nimi. Sprawdź negocjację tunelu zapasowego, jego trasy i rzeczywisty przepływ aplikacji w obu kierunkach. W przypadku BGP żywe sąsiedztwo jest użytecznym dowodem, ale nie tym samym co potwierdzenie prefiksów. W przypadku routingu statycznego potwierdź, jak brama wybiera ścieżkę i co robi, gdy preferowana zniknie.

Jeśli alternatywa nie może unieść obciążenia, zaplanuj przerwę albo napraw tunel zapasowy, zanim dotkniesz klucza. Lampka statusu na stronie konsoli nie jest obietnicą nieprzerwanej usługi.

Zrotuj jeden tunel, a potem zweryfikuj rzeczywistym ruchem

Gdy ścieżka zapasowa jest udowodniona, kolejność jest krótka. Zapisz adres tunelu, jego partnera i ustawienia niebędące tajemnicą, i utrzymuj ścieżkę zarządzania do bramy, która nie zależy od tunelu, który zaraz zerwiesz.

  1. Zaktualizuj partnera bramy klienta dla wybranego adresu zewnętrznego albo przygotuj zmianę tak, by weszła w życie sekundy po wywołaniu API.
  2. Wyślij wywołanie zmiany z nowym kluczem oraz bieżącymi czasami życia i wartościami DPD.
  3. Poczekaj, aż IKE i IPsec wrócą, a potem potwierdź trasy i wymagane prefiksy.
  4. Przepuść reprezentatywny przepływ aplikacji przez ten tunel i obserwuj oba kierunki.

Tunel jest bezużyteczny, dopóki końce się nie zgadzają i dopóki AWS stosuje zmianę, więc aktualizacja partnera musi nastąpić natychmiast, a nie po obiedzie. Dopiero gdy zmieniony tunel niesie rzeczywisty ruch, powtórz procedurę na drugim.

Zatrzymaj się, jeśli po pierwszym tunelu odzyskanie lub routing nadal są niepewne. Dwa na wpół działające tunele są gorsze niż jeden, o którym wiesz, że działa.

Gdy odzyskiwanie utknie, czytaj stronę IKE

Tunel, który pozostaje wyłączony po tym, jak oba końce mają nowy klucz, to zwykle niezgodność zasad, którą rotacja ujawniła, a nie stworzyła. Propozycje, tożsamość wysyłana przez partnera i selektory ruchu muszą się zgadzać ze stroną AWS, a wartość, która przetrwała ustanowiony tunel, nadal może zostać odrzucona podczas nowej negocjacji. Przeczytaj stan negocjacji i dołączoną do niego wiadomość, zanim zmienisz klucz po raz drugi.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Jeśli zmianę trzeba wycofać, nie przywracaj starego klucza tylko dlatego, że wcześniej działał. Traktuj ujawniony klucz jako ujawniony i napraw raczej negocjację. Zakończ z zweryfikowanymi oboma tunelami i zaktualizowanym rejestrem sekretów, tak by każdy partner zapisywał, którą wartość posiada, a dokumentację opcji tunelu AWS trzymaj obok runbooka.

Powiązane artykuły