Ograniczenia Cloud VPN, których nie da się dostroić: czas życia IKE i NAT peera
Cloud VPN negocjuje czasy życia IKE w stałych granicach i wymaga NAT jeden-do-jednego po stronie peera. Projektuj urządzenie zdalne pod to, a nie pod stronę Google.
Nadaj urządzeniu zdalnemu czas życia fazy 1 wynoszący 24 godziny, a tunel Cloud VPN pozostanie wyłączony, choć po stronie Google wszystko jest poprawnie skonfigurowane. Peer proponuje wartość, której responder nie przyjmie, więc negocjacja albo całkowicie zawodzi, albo zaczyna się od nowa w nieskończoność. Cloud VPN ogranicza fazę 1 do 36,000 sekund, czyli dziesięciu godzin, i ten limit nie jest ustawieniem, które można podnieść. Zmiana należy do urządzenia zdalnego.
Peer pyta, responder decyduje
IKE to ćwiczenie dopasowania dwóch zbiorów propozycji. Tunel powstaje tylko tam, gdzie zbiory pokrywają się w granicach akceptowanych przez respondera, dlatego czas życia poza zakresem nie tworzy żadnego częściowego tunelu. Zwykłym błędem jest traktowanie konfiguracji peera jako listy życzeń, a nie jako propozycji. Pusty przekrój pozostawia tunel wyłączony, niezależnie od poprawności routingu i selektorów.
Przeczytaj stan samego tunelu, zanim otworzysz zgłoszenie, bo szczegółowy status zwykle wskazuje etap, który zawiódł:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
Porównaj to, co wraca, z obsługiwanym zbiorem dla twojego typu bramy i wersji IKE, i zapisz oba selektory ruchu, póki tam jesteś. Niezgodność selektora daje ten sam objaw wyłączonego tunelu co niezgodność algorytmu, a w odróżnieniu od algorytmu tę musisz naprawić sam.
36,000 sekund to pułap
Faza 1 zatrzymuje się na 36,000 sekundach. Urządzenie ustawione na 86,400 prosi o coś, na co responder nigdy się nie zgodzi, a ponawianie nie zmienia jego zdania. Cofnij propozycję zdalną do zakresu, a ta sama konfiguracja się zestawi; asymetria jest całą lekcją, bo możesz obniżyć swoją wartość, a nie możesz podnieść wartości Google.
Zapisz wybraną wartość w notatkach projektowych. Inaczej następny inżynier powtórzy eksperyment z 24 godzinami i trafi na tę samą ścianę.
Obsługiwany zbiór jest publikowany dla każdego typu bramy i wersji IKE w przeglądzie Cloud VPN, więc czytaj sekcję dla swojej topologii, a nie ogólny przewodnik po IKE.
Tunel, który pada według harmonogramu
Faza 2 zachowuje się inaczej: gdy oba końce się nie zgadzają, odświeżanie kluczy podąża za krótszym interwałem. Peer, który uznaje niezgodność za fatalną, zamiast tego zrzuca tunel, więc jedna niezgodność może wyglądać jak dwie niepowiązane awarie. Obserwuj rytm odświeżania kluczy, nie tylko pierwsze połączenie. Tunel, który wstaje i potem pada w regularnym takcie, częściej oznacza niezgodność czasu życia niż defekt routingu.
Powiąż te znaczniki czasu padnięć z własnymi logami peera, zanim cokolwiek zmienisz, bo zmiana selektora lub trasy może naśladować ten sam rytm. Jeśli takt pasuje do timera fazy 2, przyczyna jest znaleziona bez dotykania propozycji.
Zestawy pochodzą z typu bramy
Zestawy szyfrowania i integralności nie są profilem na tunel, który edytujesz tak, jak pozwala strongSwan. Wybierasz je według typu bramy i wersji IKE, a szukanie nieistniejącego profilu marnuje całe popołudnie.
Stare urządzenie, które niczego nie oferuje w obsługiwanym zbiorze, pozostawia dwie uczciwe drogi: wymień urządzenie albo zakończ na bramie programowej, którą kontrolujesz, i stamtąd kieruj ruch do VPC. Cokolwiek innego jest obejściem, które nie przejdzie następnego przeglądu.
Jeden adres zewnętrzny na urządzenie
Adres zewnętrzny peera musi być mapowany jeden-do-jednego na jego adres wewnętrzny. Przeciążona pula PAT nie może działać, bo kilka hostów za jednym publicznym adresem nie daje responderowi żadnego sposobu, by je rozdzielić. Tam, gdzie kilka hostów musi dzielić adres, tunel musi kończyć się w miejscu, które potrafi je rozróżnić.
Utrzymuj też ten adres zewnętrzny w stabilności. Przenieś urządzenie za inny NAT, a powiązanie się zerwie, choć każda propozycja nadal pasuje. Warto zapisać, które wartości są Google, a które twoje: czasy życia, zestawy i NAT jeden-do-jednego są stałe po ich stronie, natomiast propozycje, selektory, routing i priorytety BGP są twoje.