Jedno /23 zamiast dwóch /24: co zmienia się w negocjacji

Dwa sąsiednie /24 schludnie zlewają się w jedno /23, a ta schludna arytmetyka przekonuje ludzi, że zmiana jest kosmetyczna. To arytmetyka adresów, a tunelowi zależy na selektorach, które są ofertą negocjacyjną, a nie opisem sieci. Krótsza linia może pozostawić ten sam ruch chroniony, chronić więcej, niż zamierzano, albo nie objąć połowy, w zależności od tego, co obie strony gotowe są zaakceptować. Odczytanie zainstalowanego wyniku to jedyny sposób, by wiedzieć, który z tych trzech przypadków nastąpił.

Trzy fakty, które ludzie zlewają w jeden

Zbiór adresów mówi, które hosty mają być chronione. Grupowanie mówi, jak te adresy są oferowane: jeden selektor czy kilka, w jednym stowarzyszeniu czy w większej liczbie. Wynegocjowany wynik mówi, co obie strony faktycznie zainstalowały, i może być węższy niż każdy z dwóch pierwszych.

Zapisz je osobno w rekordzie zmiany. Jedna linia konfiguracji często ukrywa trzy różne odpowiedzi. Recenzent, który nie potrafi ich rozdzielić, nie może też zatwierdzić zmiany.

Co respondenta wolno zrobić z twoim agregatem

Respondent IKEv2 może zawęzić oferowaną parę selektorów do podzbioru, który jest gotów zaakceptować, i może całkowicie odrzucić ofertę, jeśli nie istnieje nic akceptowalnego. Może też wskazać, że dodatkowy ruch wymaga innego stowarzyszenia, zamiast mieścić się w tym.

Respondent, który niczego nie akceptuje, zwraca zamiast tego błąd, co przynajmniej mówi, że ofertę odrzucono, a nie po cichu zawężono.

To oznacza, że udana wymiana dowodzi, iż strony zgodziły się co do czegoś, a nie że zgodziły się co do wszystkiego, co wymieniłeś. Początkowy komunikat o powodzeniu jest punktem wyjścia do czytania wyniku, nigdy wnioskiem. Zaakceptowany podzbiór może być mniejszy niż jedno /24, przez co zainstalowany zbiór wcale nie przypomina oferty.

Gdzie podsumowanie po cichu zaciera granicę

Dwa /24 mogą mieć różne reguły usług: jedno może dopuszczać tylko protokół zarządzania, drugie ogólną aplikację. Selektor obejmujący oba adresy na poziomie IP nie zachowuje tych reguł, a podsumowanie przenosi granicę do filtrowania, które istnieje za tunelem. Wypisz reguły usług dla każdej podsieci przed agregacją, inaczej to porównanie nigdy nie nastąpi.

Wartości protokołu i portu są częścią selektora, a nie opcjonalnym dodatkiem. Jeśli pierwotna polityka je ograniczała, agregat musi nieść to samo ograniczenie, inaczej zmiana jest zmianą uprawnień w kostiumie routingu. Jeśli ograniczenie było sednem pierwotnej polityki, zachowaj je jawnie po podsumowaniu i zapisz to w rekordzie.

Odczytywanie wyniku według prefiksu

Po zmianie patrz na to, co zainstalowano, a nie na to, co skonfigurowano. Następnie wygeneruj przepływ z każdego prefiksu w każdym kierunku i sprawdź liczniki należące do stowarzyszenia, które go obsługuje. Dwa prefiksy generujące ruch w jednym stowarzyszeniu są w porządku; dwa prefiksy, z których jeden nic nie generuje, to właśnie znalezisko.

Rób to tą samą aplikacją, której używają użytkownicy. Sonda rozpoczynana na bramie testuje inną ścieżkę niż klient za nią, i właśnie w tej różnicy ukrywają się błędy selektorów. Płaski licznik na prefiksie, który powinien być zajęty, jest mocniejszym dowodem niż jakakolwiek linia logu, bo mierzy nieobecność.

Jak uczynić zmianę odwracalną

Zostaw pierwotną politykę w konfiguracji, dopóki nowa nie zostanie sprawdzona z każdej kombinacji prefiksów, i zanotuj, w którym stowarzyszeniu wylądował każdy przepływ. Jeśli strona wymienia stowarzyszenia, gdy oferta się zmienia, wycofanie musi przywrócić starą ofertę, a nie tylko stare adresy.

Skoordynuj to z właścicielem drugiego końca, zanim otworzy się okno. Podsumowanie, które jedna strona uważa za oczywiste, może być nieakceptowalnym grupowaniem po drugiej, a odkrycie tego w trakcie zmiany jest kosztowne. Uzgodnij oferowane grupowanie na piśmie, a potem porównaj je z tym, co instaluje wymiana. Trzymaj tę umowę w zgłoszeniu zmiany, a nie w wątku czatu, który zniknie w przyszłym tygodniu.