Przychodzący peer IPsec nie pasuje do żadnego profilu? Sprawdź cztery pola

Twój peer zgłasza, że tunel jest podniesiony, twoja strona nie pokazuje żadnej asocjacji bezpieczeństwa, a plik konfiguracyjny wyraźnie zawiera pasującą nazwę połączenia. Wszystkie trzy zdania mogą być prawdziwe jednocześnie. Przychodzące negocjacje są porównywane z działającą konfiguracją na podstawie adresu peera, przedstawianej tożsamości i proponowanego ruchu. Plik na dysku, który nigdy nie został wczytany, tożsamość niezgodna z oczekiwaną wartością albo para selektorów przesunięta o jeden prefiks — każde z nich daje ciszę. Przejdź cztery grupy pól w kolejności, w jakiej postępuje responder.

Zacznij od pakietu, nie od pliku

Responder odbiera żądanie IKE, szuka definicji, która może przyjąć tego peera, a następnie przechodzi do uwierzytelniania i wyboru ruchu. Jeśli w pierwszym kroku żadna wczytana definicja nie pasuje, negocjacje kończą się, zanim jakikolwiek użyteczny błąd dotrze do użytkownika.

Dlatego „konfiguracja wygląda poprawnie” nie jest dowodem. Pytanie brzmi, co wczytała działająca usługa i który wpis wybrała dla tej próby. Lista stanu odpowiada na to jednym poleceniem, a bufor edytora odpowiada na inne pytanie. Sprawdź listę, zanim ponownie zmienisz plik.

Pierwsza grupa pól: definicja, która naprawdę jest wczytana

Sprawdź działający stan narzędziem, które posiada demona: poleceniem stanu listującym wczytane połączenia, a nie buforem edytora. Potwierdź, że oczekiwany wpis istnieje, jest włączony dla zamierzonego zachowania przy starcie i został wczytany po twojej ostatniej zmianie. Zapisany, ale nieprzeładowany plik to najczęstsza przyczyna zdania „naprawiłem i nic się nie zmieniło”.

Potwierdź także, który plik czyta usługa. Dystrybucje się różnią, a połączenie zapisane w niewłaściwym dołączeniu jest po cichu ignorowane, a nie odrzucane. Jeśli lista stanu w ogóle nie pokazuje twojego wpisu, podejrzewaj ścieżkę dołączenia, zanim podejrzysz składnię.

Druga grupa pól: punkty końcowe to nie tożsamości

Adres, z którego peer się łączy, i tożsamość, którą się uwierzytelnia, to osobne pola. Nazwa hosta, nazwa wyróżniająca, identyfikator klucza i adres mogą wszystkie służyć jako tożsamość IKE w zależności od konfiguracji, i wcale nie muszą przypominać adresu publicznego.

Dopasowanie punktów końcowych może obejmować także widok NAT: adres widziany w sieci może różnić się od adresu, który peer uważa za swój. W modelu połączeń libreswan left i right to etykiety dwóch uczestników, a nie stała kolejność lokalnego i zdalnego, dlatego kopiowanie działającej konfiguracji z innej lokalizacji z zamianą adresów nie jest rzetelnym tłumaczeniem.

Zapisz oczekiwaną tożsamość obu stron i poświadczenie, które ją weryfikuje. Jeśli te dwie linie się nie zgadzają, żadne strojenie adresów nie da dopasowania.

Trzecia grupa pól: chroniony ruch

Selektory opisują wewnętrzne zakresy źródła i celu, ich rodzinę adresów oraz wszelkie ograniczenia protokołu lub portu. Propozycja dla adresu jednego hosta nie jest tym samym żądaniem co dla całej podsieci, a responder skonfigurowany dla podsieci może ją odrzucić lub zawęzić.

Gdy oba końce się nie zgadzają, porównaj zamierzony przepływ z obu punktów widzenia, zamiast rozszerzać każdy selektor, aby coś się połączyło. Zapytaj każdego administratora, jaki przepływ uważa, że chroni, a następnie porównaj obie odpowiedzi. Rozbieżność to zwykle prefiks hosta po jednej stronie i podsieć po drugiej. Tunel, który pasuje, bo teraz chroni wszystko, jest inną decyzją bezpieczeństwa i taką, której nikt nie zatwierdził.

Czwarta grupa pól: czytasz jedną implementację

Libreswan, stary Openswan i strongSwan mają różne narzędzia zarządzania, różną składnię konfiguracji i różną kolejność dopasowania. Działający przykład z jednego nie mówi nic dokładnego o priorytecie wyboru profilu ani o brzmieniu błędów drugiego, więc weryfikuj z dokumentacją demona na tym hoście.

Skorelowanie jednej próby od początku do końca: adres źródłowy inicjatora, oferowana tożsamość i proponowane selektory — wobec komunikatu wyboru respondera i nazwanego przez niego wczytanego wpisu. Zerowe liczniki enkapsulacji i dekapsulacji mówią tylko, że zaobserwowane asocjacje nie przeniosły tych pakietów; nie nazywają punktu końcowego, który odrzucił propozycję, i nie dowodzą, że w tej chwili istniał pasujący wpis.

Po uzgodnionej poprawce potwierdź wybrany profil i asocjację, a następnie sprawdź faktycznie dozwoloną usługę i jej ścieżkę odpowiedzi. Dopasowanie profilu umożliwia negocjacje, a negocjacje nie są ostatnią kontrolą dostępu.