FortiGate Azure rekey: propozycja peer SA nie pasuje do lokalnej polityki
Działający tunel IKEv2 nadal może odrzucić zastępczą CHILD SA. Porównaj propozycję, którą odnowienie rzeczywiście negocjuje, a nie tę, której użył pierwszy ping.
Tunel się podniósł, ruch płynął, a później w logu pojawia się peer SA proposal not match local policy. Większość ludzi czyta ten wiersz jako dowód, że obie konfiguracje nigdy nie były zgodne. Zwykle znaczy to coś węższego: były zgodne dla pierwszej CHILD SA i przestały być zgodne przy pierwszym odnowieniu, bo pierwsza asocjacja nigdy nie potrzebowała wymiany, którą wykonują kolejne. To rozróżnienie decyduje, gdzie patrzeć.
Pierwsza CHILD SA dziedziczy, kolejne negocjują
W IKEv2 początkowa CHILD SA powstaje podczas IKE_AUTH, a jej klucze są wyprowadzane z materiału kluczowego IKE SA. W tym momencie nie ma osobnej wymiany Diffie-Hellmana, więc grupa PFS, której jeden peer nie może zaakceptować, po prostu nie jest jeszcze testowana. Tunel wygląda zdrowo, bo wymóg, na którym później zawiedziesz, nigdy nie został sprawdzony.
Odnowienie klucza CHILD_SA to inna sekwencja komunikatów. Gdy PFS jest skonfigurowany, peery wykonują świeżą wymianę kluczy i muszą uzgodnić grupę akceptowaną przez obie strony oraz propozycję ESP dla nowej asocjacji. To właśnie ten moment, w którym niezgodność staje się widoczna, i dlatego błąd wskazuje propozycję, a nie trasę.
Więc „wczoraj działało” nic nie mówi o propozycji. Mówi, że początkowa wymiana się powiodła, co już wiedziałeś.
Czytaj nieudaną wymianę, nie pierwszy ping
Zanim cokolwiek zmienisz, zbierz z obu stron udane uwierzytelnienie IKE, początkową CHILD SA i nieudane zastąpienie. Potem nazwij operację precyzyjnie: odnowienie klucza IKE SA, ponowne uwierzytelnienie IKE i odnowienie klucza CHILD SA to trzy różne zdarzenia, a „faza 2” w potocznej rozmowie obejmuje je wszystkie.
Porównaj pola poniżej dla połączenia, które zawiodło, a nie dla tunelu ogólnie.
| Warstwa | Wartości do porównania |
|---|---|
| IKE | Wersja, szyfrowanie i integralność lub układ PRF, grupa DH |
| IPsec / CHILD | Szyfrowanie i integralność ESP, zamierzona grupa PFS lub wymiany kluczy |
| Chroniony ruch | Selektory lokalne i zdalne oraz dowolne ustawienie selektora oparte na polityce |
Na FortiGate otwórz propozycję fazy-2, ustawienie PFS i zaakceptowane grupy DH dla tego tunelu. Czytaj załadowane wartości, zamiast wywnioskować je z połączenia nawiązanego wcześniej. Zrzut ekranu strony GUI jest słabszym dowodem niż działająca konfiguracja, bo po aktualizacji oba mogą się różnić. Wyeksportuj zmienioną sekcję i zachowaj ją razem z zgłoszeniem.
Domyślna polityka Azure wciąż jest polityką
Brak własnej polityki dołączonej do połączenia nie oznacza, że Azure nie stosuje żadnej. Połączenie wraca do domyślnego zestawu propozycji bramy, który może być szerszy lub węższy niż to, co oferuje twój FortiGate. Jeśli oba zestawy pokrywają się dla IKE, ale nie dla ESP z PFS, dostajesz dokładnie taki wzorzec awarii.
Ten widok tylko do odczytu pokazuje faktycznie dołączoną politykę, nie ujawniając sekretów:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesUżyj rzeczywistych nazw swoich zasobów. Gdy potrzebna jest jawna polityka, ustaw ją na zasobie połączenia. To nie jest przełącznik dla całej bramy i nie stosuje się po cichu do innych tuneli na tej samej bramie.
W portalu strona Configuration tego połączenia to miejsce, w którym trafia własna polityka IPsec/IKE. Przewodnik Microsoftu po politykach niestandardowych wymienia obsługiwane parametry i wymagania SKU. Azure przyjmuje jedną pełną kombinację na połączenie, więc podajesz pola IKE i pola IPsec razem, a nie jedno po drugim.
PFS to wymóg, a nie przełącznik do przestawienia
Jeśli twoja podstawa bezpieczeństwa wymaga PFS, rozwiązaniem jest grupa akceptowana przez oba peery po obu stronach, wyrażona przez pasującą politykę. Wyłączenie PFS, żeby błąd zniknął, zmienia właściwość bezpieczeństwa, którą próbowałeś zachować, i zwykle później wraca jako inna niezgodność.
Jedna pułapka specyficzna dla Azure: gdy wybierasz GCM dla ESP, wybory szyfrowania i integralności muszą wskazywać ten sam algorytm GCM i tę samą długość klucza. Mieszanie szyfru GCM z osobnym algorytmem integralności daje kombinację, którą usługa odrzuca, i wygląda to jak niezgodność peerów, dopóki uważnie nie przeczytasz polityki.
Wybierz najsilniejszą kombinację, którą obsługują oba końce i na którą pozwala twój wymóg, a potem zapisz ją w rejestrze zmian. Następna osoba porówna się z tym rejestrem, a nie ze wspomnieniem działającego tunelu. Umieść w nim grupę PFS i propozycję ESP, nie tylko nazwę polityki. Gdy ktoś później zapyta, dlaczego audyt się nie powiódł albo dlaczego odnowienie klucza jest wolne, ten wiersz odpowiada na oba pytania.
Zweryfikuj wymianę, która zawiodła
Zaplanuj zmianę ze ścieżką odzyskiwania, bo edycja polityki może przerwać tunel, który próbujesz naprawić. Gdy ruch wróci, poczekaj na odnowienie CHILD_SA lub je wywołaj i potwierdź, że nowa asocjacja została nawiązana z zamierzoną grupą PFS. Następnie potwierdź, że ruch aplikacji nadal przez nią przechodzi.
Dwa fałszywe tropy warto nazwać. Czasy życia SA to specyfikacje lokalne, więc nierówne wartości są normalne, a ich zmiana tylko przesuwa moment, w którym problem się pojawia. DPD wykrywa, czy peer żyje; podniesienie limitu czasu nie wyrównuje wyborów ESP ani PFS.
Zapisz wynegocjowany wynik i następne zdarzenie po zmianie. Jeśli połączenie teraz zawodzi przed ukończeniem uwierzytelnienia IKE, patrzysz na ustawienia IKE, które właśnie edytowałeś, a nie na pierwotną awarię odnowienia CHILD.