Polityka IPsec połyka twój lokalny ruch: jak to rozpoznać

Drukarka na biurku przestaje odpowiadać w chwili, gdy tunel się podnosi, a nic w konfiguracji tunelu nie wspomina o drukarce. Zwykle stało się tak, że chroniony zakres zapisano na tyle szeroko, by ją obejmował, więc maszyna próbuje teraz szyfrować ruch, który powinien zostać w segmencie lokalnym. Odczytanie zainstalowanej polityki wyjaśnia przechwycenie; zawężenie jej w odpowiednim miejscu utrzymuje ochronę ruchu zdalnego. Droga od nieudanego żądania do pasującej polityki zajmuje kilka minut.

Prześledź przepływ, zanim zmienisz selektor

Zacznij od nieudanego żądania i zapisz cztery wartości: adres źródłowy, którego używa maszyna, dokładny cel, trasę wybieraną przez jądro i politykę pasującą do tej pary.

Te cztery fakty decydują, czy przechwycenie jest zamierzone, czy przypadkowe. Cel mieszczący się w zdalnym selektorze jest chroniony z założenia, nawet jeśli założenie było błędne. Cel poza nim, który mimo to jest przechwytywany, oznacza, że pasuje coś innego, a zmiana selektora nie pomoże. Oba przypadki są częste i odróżnia je jedno polecenie.

Zrób to, zanim cokolwiek edytujesz, bo interesujący przypadek to lokalna podsieć, która nakłada się na zakres prywatny chroniony przez połączenie. Znane prefiksy, takie jak 192.168.0.0/16, występują w wielu sieciach, a selektor zapisany dla jednego z nich może po cichu objąć twój.

Trzy rodzaje lokalności, które zachowują się inaczej

Cel przypisany do tego hosta, cel w tym samym łączu i cel za innym interfejsem to trzy różne przypadki. Jądro traktuje każdy inaczej, gdy decyduje, czy ruch wymaga ochrony.

Ruch generowany przez samą bramę też nie jest tym samym co ruch przekazywany od klienta. Polityka, która wygląda poprawnie dla ruchu przekazywanego, może przechwycić własną sesję zarządzania bramy, i tak administrator traci dostęp, naprawiając tunel.

Przydatny nawyk to nazwanie przypadku na głos: czy ten pakiet pochodzi ode mnie, idzie do mojego łącza, czy przeze mnie? Każda odpowiedź wskazuje inne miejsce do zawężenia. Zapisanie przypadku powstrzymuje też następną osobę przed powtórzeniem tej samej pracy.

Gdy chroniony zakres to cała przestrzeń prywatna, wszystkie trzy przypadki mogą się w nim znaleźć naraz, a objawem staje się maszyna, która nie dociera do niczego poza punktem końcowym tunelu.

Czytaj zainstalowaną politykę, nie plik

Pliki konfiguracji opisują intencję; jądro przechowuje polityki, które faktycznie pasują. Pokaż oba i potraktuj rozbieżność jako pierwsze ustalenie.

Te polecenia pokazują wybraną trasę do celu i zainstalowane polityki w każdym kierunku:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Trasa mówi, którego interfejsu użyłby pakiet. Lista polityk mówi, czy do tego pakietu zostanie następnie zastosowany szablon, a lista połączeń pokazuje, jakie selektory demon uważa za zainstalowane. Jeśli cel pojawia się w zdalnym selektorze, znalazłeś przechwycenie bez zgadywania.

Zawęź selektor albo omiń cel

Są dwie obsługiwane naprawy i odpowiadają na różne pytania. Zawężenie selektora mówi, że to połączenie chroni tylko mniejszy zakres, co jest słuszne, gdy szerszy zakres był błędem. Dodanie obejścia mówi, że ten konkretny cel nigdy nie może być chroniony, co jest słuszne, gdy chroniony zakres naprawdę jest szeroki, a jeden cel jest wyjątkiem.

Wybierz pierwszą, gdy możesz, bo mniejszy selektor łatwiej zrozumieć i widać go w definicji połączenia. Wybierz drugą, gdy szeroki zakres jest zamierzony, a wyjątkiem jest pojedynczy host lub podsieć, którą możesz nazwać.

Oba należą do konfiguracji, która jest właścicielem połączenia. Reguła czasu wykonania dodana ręcznie zniknie przy następnym ponownym połączeniu, a awaria wróci w chwili, gdy nikt nie pamięta obejścia.

Wyjątki bezpieczne przy ponownej instalacji

Po zmianie powtórz to samo nieszkodliwe żądanie i spójrz na te same liczniki. Cel lokalny powinien odpowiedzieć, a zamierzony cel zdalny powinien nadal pokazywać zaszyfrowany ruch.

Te dwa testy potwierdzają, że wyjątek przetrwał, a ochrona nie:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Potem celowo rozłącz i ponownie połącz tunel, i powtórz oba. Wyjątek, który działa przed ponownym połączeniem i zawodzi po nim, został zastosowany na złej warstwie, i to najczęstszy sposób, w jaki ten problem wraca.