Twoja reguła VPN dla IPv4 nic nie mówi o ruchu IPv6

Audyt ujawnia, że tunel jest na tym samym interfejsie szczelnie filtrowany dla IPv4 i szeroko otwarty dla IPv6. Nic nie było źle skonfigurowane w sensie literówki; zestaw reguł po prostu opisywał jedną rodzinę, a wszyscy zakładali, że druga podąża za nią. Rzadko tak się dzieje. Trzy warunki decydują, czy reguła naprawdę obejmuje obie, a pierwszy dotyczy platformy, a nie polityki.

Warunek pierwszy: czy platforma ma jedną tabelę, czy dwie

Niektóre filtry pakietów trzymają IPv4 i IPv6 w całkowicie odrębnych zestawach reguł, więc reguła dodana do jednego nie działa na drugi, dopóki ktoś jej nie zduplikuje. Inne oferują rodzinę pasującą do obu i tłumaczą adresy dla każdego pakietu. Trzecia grupa trzyma jeden język polityki, ale przechowuje za nim osobne obiekty dla każdej rodziny.

Przeczytaj dokumentację filtra, którego naprawdę używasz, a następnie wypisz, które tabele istnieją i której dotyczyła twoja zmiana. Liczenie reguł w tabeli IPv4 odpowiada na pytanie, którego nikt nie zadał. Następnie wypisz, które tabele istnieją i której dotyczyła twoja zmiana.

Warunek drugi: gdzie polityka obowiązuje

Trzy miejsca są ze sobą mylone: nasłuch, który przyjmuje tunel, ścieżka, która przekazuje ruch dalej, oraz zwykły interfejs, którego klient używa, gdy tunel nie niesie przepływu. Brama może przyjąć sesję, a jednocześnie odrzucać wszystko, co z niej przekazano, i wygląda to na zepsuty tunel, a nie filtr. Usuń to zamieszanie, zanim cokolwiek napiszesz, ponieważ te trzy miejsca mają różnych właścicieli i różne dzienniki. Nazwanie ich w zapisie zmiany jest tym, co nie pozwala poprawce wylądować o warstwę dalej od usterki.

Zapisz, którym z trzech miejsc ma rządzić twoja reguła. Reguła chroniąca nasłuch nie chroni przekazywanej ścieżki i żadna z nich nie zamyka bezpośredniej trasy klienta. Zwróć uwagę, do kogo należy każde miejsce, bo odpowiedzią w większości organizacji jest inny zespół.

Warunek trzeci: co powinien robić IPv6

Zdecyduj, czy IPv6 przechodzi przez tunel, jest blokowany, gdy ochrona jest niedostępna, czy stosuje udokumentowany wyjątek. Każda odpowiedź daje inny zestaw reguł, a pozostawienie pytania otwartego sprawia, że klient z natywnym IPv6 dociera poza tunelem do miejsc, do których dociera w nim przez IPv4.

Powiedz odpowiedź na głos, zanim napiszesz reguły. Blokowanie to uzasadniony wybór dla tunelu, który nie niesie IPv6, o ile jest zamierzone i przetestowane, a nie przypadkowym wynikiem pustej tabeli. Wszystko nieudokumentowane zostanie rozstrzygnięte ponownie przez tego, kto następny dotknie reguł, i zwykle w pośpiechu.

ICMPv6 to ruch sterujący

Wykrywanie sąsiadów i informacja zwrotna o ścieżce jadą oba po ICMPv6, więc zbiorcze odrzucanie skopiowane z nawyku IPv4 psuje adresowanie i duże transfery jednocześnie. Zbiorcze zezwolenie też nie jest odpowiedzią, bo oddaje kanał, którego nikt nie pilnuje.

Postępuj zgodnie ze wskazówkami filtrowania dla ważnych typów komunikatów, a resztę odrzucaj z podaniem przyczyny. Usterką najczęściej błędnie diagnozowaną jest brakujący komunikat Packet Too Big, który objawia się połączeniem, które się otwiera, a potem zatyka.

Udowodnić to, jedna rodzina na raz

Przetestuj autoryzowane żądanie przez każdą rodzinę osobno, a potem powtórz po ponownym połączeniu, jeśli polityka ma przetrwać sesję. Test w sieci tylko z IPv4 nie może przećwiczyć trasy IPv6, więc powodzenie nic nie mówi o wycieku, który próbujesz zamknąć. Obserwuj liczniki podczas testu, bo reguła, która nigdy nie pasuje, nie robi tego, co twierdzi jej komentarz.

Zmieniaj jedną ograniczoną regułę na próbę i trzymaj poprzednią konfigurację pod ręką. Tam, gdzie polityką zarządza profil zarządzany, zaangażuj jego administratora przed lokalną edycją, bo następne sprawdzenie nadpisze lokalną poprawkę i przywróci wyciek.