Pięć ról adresu w profilu IPsec i która z nich jest błędna

Pięć różnych zadań otrzymuje adres w typowej definicji połączenia i nie muszą się one ze sobą zgadzać. Administratorzy utykają, ponieważ rozsądny odruch, czyli skierowanie wszystkich pól na ten sam host, jest błędny w przypadku co najmniej trzech z nich. Wyjściem jest najpierw nazwanie objawu, a potem spojrzenie na jedno lub dwa pola, które mogły go wywołać.

Pięć zadań, w kolejności ważności

Punkt końcowy transportu to miejsce, do którego dostarczana jest wymiana IKE. Uwierzytelniona tożsamość to nazwa, którą dowodzi każda strona, i jest ona sprawdzana wobec polityki, a nie wobec tablicy routingu. Chronione podsieci to selektory, które decydują, jaki ruch wewnętrzny należy do tunelu. Potem jest źródło używane, gdy sama brama rozpoczyna rozmowę, a na końcu następny skok warstwy niższej, aby dotrzeć do partnera.

Etykiety uczestników, takie jak left i right, są konwencjami dla dwóch stron połączenia, a nie synonimami lokalnego i zdalnego. Przeczytaj instrukcję rzeczywiście zainstalowanej implementacji, zanim uznasz, że klucz znaczy to, co miał na myśli inny produkt.

Decyzja pierwsza: nic się nie ustanawia

Gdy w logach w ogóle nie pojawia się wymiana, punkt końcowy jest pierwszym podejrzanym: zły adres, filtrowana ścieżka lub interfejs, na którym demon nie nasłuchuje. Do pól tożsamości przejdź dopiero wtedy, gdy uścisk dłoni jest widoczny, bo tożsamość jest oceniana wewnątrz wymiany, a nie przed nią. Filtrowana ścieżka i zły adres wyglądają z perspektywy klienta identycznie, więc sprawdź stronę nasłuchującą, zanim cokolwiek zmienisz. Potwierdź, że demon jest związany z interfejsem, którego oczekujesz, bo usługa nasłuchująca na jednym adresie wygląda dokładnie jak zablokowana ścieżka.

Publiczny adres zaobserwowany przez tłumaczenie to nie to samo, co tożsamość dowodzona przez partnera. Zmiana adresu tak, aby pasował do tego, co pokazuje przechwycenie pakietów na dalekim końcu, jest częstą i błędną poprawką.

Decyzja druga: tunel stoi, a ruch ginie

Selektory decydują, co wchodzi do tunelu, a niezgodność tutaj daje połączenie, które skutecznie negocjuje, podczas gdy aplikacja nadal zawodzi. Strona zdalna musi nazwać twój chroniony zakres jako swój zakres zdalny, i właśnie tam wkradają się odwrócone wartości.

Przeczytaj obie konfiguracje obok siebie, zanim zaczniesz edytować. Zakres lokalny na jednym hoście jest zakresem zdalnym na drugim, a jedna zamieniona para wyjaśnia tunel, który niczego nie przenosi. Zawęź parę, zanim dotkniesz kluczy: jedna podsieć wewnątrz tunelu i jedna na zewnątrz mówią ci, czy winny jest selektor, czy routing.

Decyzja trzecia: zawodzi tylko własny ruch bramy

Ruch przekazywany dla klientów może działać bezbłędnie, podczas gdy żądanie rozpoczęte przez samą bramę zawodzi, bo ten strumień nie ma źródła klienta do odziedziczenia. Ustawienie preferowanego źródła istnieje właśnie dla tego przypadku i nie jest tłumaczeniem źródła: wybiera adres źródłowy, zamiast go przepisywać.

Aplikacja, która jawnie wiąże inny adres, może ominąć preferencję, więc potwierdź rzeczywiste źródło pakietu, zanim uznasz, że ustawienie jest ignorowane. Przechwytuj na własnym interfejsie bramy, zamiast ufać intencji konfiguracji.

Następny skok to lokalna instrukcja

Następny skok warstwy niższej mówi temu hostowi, jak dotrzeć do partnera, a strona zdalna nie potrzebuje tej samej wartości. Traktowanie go jako ustawienia wspólnego albo twarde zakodowanie bramy domyślnej psuje się w chwili, gdy zmieni się trasa lub pojawi się druga ścieżka.

Niektóre implementacje oferują tu specjalne wartości. To, co instrukcja wymienia dla zainstalowanej wersji, jest jedyną bezpieczną odpowiedzią, a lokalna tablica routingu jest dowodem, że zadziałało. Gdy partner jest osiągalny po nazwie, ale nie po adresie, ta niezgodność jest ustaleniem, a nie szczegółem do obejścia.

Czytaj profil z obu końców

Odwrócenie ról na papierze to najszybszy przegląd, jaki istnieje: zamień chronione zakresy, zachowaj własny następny skok każdej strony i własną tożsamość każdej strony. Wszystko, co nie przetrwa zamiany, jest prawdopodobnie przypisane do niewłaściwego zadania.

Następnie przetestuj jeden strumień na rolę: osiągalność między partnerami, wewnętrzny strumień klienta i żądanie pochodzące z bramy. Trzy testy mówią, które zadanie jest źle przypisane, bez ponownego otwierania konfiguracji. Dodaj wynik do zgłoszenia obok pola, które zmieniłeś, bo następny inżynier spotka ten sam profil.