IKEv2 w Windows i FortiGate: trzy ustawienia, które ludzie łączą
Wymiana kluczy IKE, ochrona CHILD SA i uwierzytelnianie partnera to trzy osobne wiersze. Zgodność numerów grup w dwóch oknach nie łączy ich.
Uzgodnienie IKEv2 między klientem Windows a bramą FortiGate wciąż kończy się niepowodzeniem, a szukanie niezgodnego numeru daje jeszcze dłuższą listę numerów. Lista staje się ogarnialna dopiero wtedy, gdy podzieli się ją na trzy wiersze, które zawodzą niezależnie: wymianę kluczy chroniącą IKE, ochronę stosowaną do CHILD SA oraz uwierzytelnianie, które dowodzi, kim jest każda strona. Numery grup pojawiają się w dwóch z tych wierszy i znaczą różne rzeczy.
Trzy wiersze, które zawodzą niezależnie
Pierwszy wiersz to wymiana kluczy wewnątrz samego IKE, która tworzy klucze chroniące negocjację. Drugi to propozycja dla CHILD SA, która chroni ruch przenoszony przez tunel. Trzeci to uwierzytelnianie, które decyduje, co przedstawia każda strona i jak druga ją weryfikuje.
Awarie trafiają w różne miejsca. Awaria wymiany zatrzymuje negocjację, zanim powstanie jakikolwiek tunel. Awaria CHILD SA następuje po udanym uwierzytelnieniu, czasem tylko przy odświeżeniu kluczy. Awaria uwierzytelniania może w logach wyglądać jak awaria wymiany, jeśli czytasz tylko pierwszy błąd.
Rozdzielenie wierszy nie jest księgowością. Zmienia to, które ustawienie warto zmienić, i zapobiega najdroższemu ruchowi w całej tej dziedzinie, czyli ponownemu generowaniu działających certyfikatów, by naprawić niezgodność propozycji. Zmiana jednego wiersza nigdy nie powinna zmuszać pozostałych dwóch do zmiany razem z nią. Ta niezależność jest całym sensem pisania ich osobno.
Co kontrolują dwa pola Windows
Windows trzyma dwa pola osobno: DHGroup konfiguruje samą wymianę IKE, natomiast PfsGroup konfiguruje zasady IPsec chroniące ruch w tunelu. Należą do różnych faz. Porównanie pola IKE w Windows z wartością fazy 2 w FortiGate testuje niewłaściwą parę, a numery mogą się zgadzać, podczas gdy sama wymiana wciąż zawodzi.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSADrugie i trzecie polecenie raportują skojarzenia zabezpieczeń, które faktycznie istnieją, i to jest najbliższe odpowiedzi, jakiej klient może ci udzielić. Skojarzenie w trybie głównym bez skojarzenia w trybie szybkim to problem CHILD SA i jest to oznaka niezgodności fazy 2, a nie problemu z certyfikatem.
Zapisz, co zaproponowano i co wybrano w jednej próbie. Lista propozycji zawierająca akceptowalną propozycję oraz wybrana propozycja niezgodna z zasadami bramy to niezgodność konfiguracji, a nie tajemnica interoperacyjności.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Grupa krzywej eliptycznej nie wybiera twojego klucza podpisu
Najbardziej uporczywym błędnym wnioskiem w tej dziedzinie jest to, że wybór grupy DH krzywej eliptycznej wymaga certyfikatu krzywej eliptycznej. Grupa DH dostarcza materiał do wymiany kluczy; algorytm podpisu negocjuje rama uwierzytelniania, a to dwie osobne decyzje w IKEv2.
RFC 7427 istnieje właśnie dlatego, że te decyzje były wcześniej splątane, i określa, jak algorytmy podpisu są ogłaszane i wybierane niezależnie od wymiany kluczy. Brama może jednocześnie obsługiwać grupę krzywej i wybór schematów podpisu.
Gdy więc negocjacja zawodzi po zmianie grupy, spójrz na metodę uwierzytelniania, zanim spojrzysz na typ klucza certyfikatu. Zmiana certyfikatu to wolna i ryzykowna operacja, która rzadko jest odpowiedzią, a zrobienie jej najpierw niszczy twoją zdolność ustalenia, która zmiana naprawdę pomogła. Przeczytaj wiersz uwierzytelniania, zanim dotkniesz magazynu certyfikatów.
Trzymaj oba w osobnych wierszach arkusza uzgodnień, a błąd przestanie być kuszący. Jeden wiersz wymienia grupy, drugi schematy podpisu i tożsamości, i żaden nie jest dowodem na drugi.
Umieść każdy klucz prywatny przy jego rzeczywistym właścicielu
Brama, która przedstawia własny certyfikat, potrzebuje pasującego do niego klucza prywatnego. Partner, który weryfikuje łańcuch, potrzebuje certyfikatu CA i konkretnie nie potrzebuje klucza podpisu CA. Mieszanie tych trzech artefaktów to sposób, w jaki ludzie importują prywatny klucz CA do urządzenia VPN, aby certyfikat pojawił się w innej kategorii.
W FortiOS role są odrębne: certyfikat lokalny z kluczem, certyfikat zdalny używany do identyfikacji partnera oraz wpis zdalnego CA, który ustanawia zaufanie do certyfikatów podpisanych przez to CA. Wpis zdalnego CA bez klucza prywatnego nie jest niekompletny; jest poprawny dla swojego celu.
Zaimportowane klucze podpisu CA poszerzają uprawnienia każdego, kto może czytać to urządzenie. Nie rozwiązują też zwykłej weryfikacji partnera, bo weryfikacja wymaga publicznego certyfikatu i decyzji o zaufaniu, a nie zdolności wystawiania nowych certyfikatów.
Trzymaj klucz podpisu CA przy procesie samego wystawcy i zapisuj, które urządzenie trzyma który klucz. Krótka tabela właścicieli jest warta więcej niż dłuższa tabela algorytmów, gdy audyt pyta, kto mógł podszyć się pod kogo. Nikt nie importuje klucza, o którym wie, że służy tylko do inwentaryzacji. Napisz inwentarz przed incydentem, nie po nim.