pull-filter w OpenVPN pasuje do więcej niż zamierzona trasa

Dodajesz jedną linię, aby zachować lokalną trasę domyślną, i po tym tunel nie dociera już do wewnętrznego serwera DNS. Ta linia to pull-filter ignore "route", co nie znaczy "zignoruj tę trasę". Znaczy "odrzuć każdą wypychaną opcję, której tekst zaczyna się od tych pięciu liter", a na zwykłym serwerze obejmuje to route-gateway, route-metric i route-ipv6 wraz z samymi trasami. Poniższa lista kontrolna to coś, co przechodzę, zanim dotknę profilu, którego musi używać ktoś inny.

Filtr działa tylko na wypychane opcje

pull-filter działa wyłącznie na wierszach opcji, które serwer wysyła po zestawieniu tunelu, i na niczym innym. Opcje zapisane w twoim lokalnym pliku nie są przez to objęte, podobnie jak ruch aplikacji. Jeśli miałeś nadzieję powstrzymać proces przed korzystaniem z tunelu, to jest całkowicie niewłaściwe narzędzie i żadna kombinacja filtrów tego nie zrobi.

Ten zakres jest przydatny, bo oznacza, że możesz zostawić konfigurację serwera w spokoju i mimo to lokalnie odrzucić jej część. To także ograniczenie, które warto zapisać w zgłoszeniu: filtr zmienia to, co akceptuje ten klient, a nie to, co oferuje serwer. Nie ma żadnego wpływu na innych użytkowników tego samego profilu. Nie przetrwa też przejścia na innego klienta, który nie implementuje tej opcji, co warto wiedzieć, zanim zbudujesz na tym przepływ pracy.

Zanim napiszesz wzorzec, potwierdź, co serwer faktycznie wysyła. Przy wysokiej szczegółowości klient wypisuje otrzymany ciąg wypychanych opcji, i to jest jedyne uczciwe źródło dokładnego tekstu, z którym porównujesz:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Czytaj wypchnięty wiersz jako listę opcji rozdzielonych przecinkami i zauważ, że nazwy opcji i ich argumenty są rozdzielone spacjami. Tekst filtra jest porównywany z tym strumieniem, dlatego w następnym kroku spacje mają tak duże znaczenie.

Dopasowanie to prefiks, więc spacje decydują o wszystkim

Porównanie jest prefiksem ciągu, a nie sparsowaną nazwą opcji. Dlatego "route" pasuje do route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 i route-metric 100. Jedna spacja na końcu zawęża go do rodziny, którą prawdopodobnie miałeś na myśli, a pełny prefiks zawęża go jeszcze bardziej do konkretnego celu.

Ostatni wiersz to ten, który łapie ludzi podczas pracy z dzielonym tunelem. Zachowanie własnego resolvera jest uzasadnionym wyborem i oznacza, że każda nazwa wewnętrzna zależy teraz od resolvera, który nie widzi strefy prywatnej. To konsekwencja przyjmowana świadomie, a nie efekt uboczny odkrywany na produkcji.

Dopasowanie po prefiksie oznacza też, że reguła może później cicho się rozszerzyć. Gdy serwer dodaje nową opcję zaczynającą się od twojego tekstu, filtr zaczyna jej dotyczyć, mimo że nikt nie edytuje twojego profilu. To właśnie tryb awarii, przeciwko któremu trzeba projektować, a złagodzeniem jest dopasowanie jak największej części opcji, a nie jak najmniejszej.

Trzy czasowniki, trzy różne wyniki

accept, ignore i reject to nie trzy zapisy tego samego pomysłu. Różnią się tym, co klient robi z dopasowaniem, i tym, czy ktokolwiek się o tym dowie.

ignore po cichu odrzuca pasującą opcję, czego chcesz dla ustawienia, które świadomie zastąpiłeś. reject odrzuca ją i każe klientowi narzekać, czego chcesz, gdy jej brak powinien być widoczny w logu, a nie odkryty później. accept to forma pozytywna, używana, gdy budujesz listę dozwolonych, a nie usuwasz pojedyncze opcje.

Jakiegokolwiek czasownika użyjesz, filtry są stosowane w kolejności występowania, więc dwie nakładające się reguły dają wynik zależny od kolejności, który bardzo trudno przejrzeć. Trzymaj jedną regułę na intencję i w każdej umieść najbardziej konkretny tekst. Jeśli potrzebujesz listy dozwolonych, wybierz kilka reguł accept zamiast stosu reguł ignore, które sumują się do tego samego. Wtedy recenzenci mogą przeczytać plik od góry do dołu i przewidzieć wynik, a to jedyny test, który się skaluje.

Sprawdź zastosowaną trasę i resolver, nie profil

Filtr, który wygląda poprawnie w pliku, wciąż może zostawić cię z tunelem, który nie kieruje niczego użytecznego. Zweryfikuj efekt w działającym systemie, gdzie wypychane opcje zostały już zastosowane lub odrzucone:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

Pierwsze dwa wiersze mówią ci, czy dotarła wypchnięta trasa domyślna i ile wpisów statycznych przetrwało. Zapytanie do resolvera pokazuje, którego serwera faktycznie używa interfejs tunelu, i tam zwykle pojawia się niespodzianka DNS. Ostatni wiersz odpowiada na jedyne pytanie, które ma znaczenie dla użytkownika.

Przetestuj oba kierunki, póki tam jesteś. Reguła, która utrzymuje twoje lokalne połączenie z internetem, ale po cichu psuje wewnętrzne rozwiązywanie nazw, przechodzi powierzchowną kontrolę i zawodzi przy pierwszym prawdziwym zadaniu, więc uwzględnij w tym samym teście jeden zasób wewnętrzny i jedną stronę publiczną.

Zapisz wyjątek i jego właściciela

Filtr jest wyjątkiem od projektu operatora, więc zapisz go z uzasadnieniem i punktem przeglądu. "Ignoruje wypychane trasy, aby zachować lokalną domyślną" jest przeglądalne; goły wiersz w profilu nie, a następna osoba usunie go lub rozszerzy na wyczucie.

Wersja też tu ma znaczenie. Zachowanie dopasowania i dokładna akceptowana składnia były dopracowywane w OpenVPN 2.4, 2.5 i 2.6, więc potwierdź wzorzec w instrukcji tej kompilacji, którą dostarczasz, a nie w poście na forum o starszej wersji. Instrukcja OpenVPN 2.6 dokumentuje tę opcję i jej regułę dopasowania.

Na koniec uzgodnij wyjątek z tym, kto zarządza serwerem. Filtr po stronie klienta sprzeczny z celową polityką serwera to incydent wsparcia czekający na następny audyt, i znacznie taniej jest go rozstrzygnąć przed wysłaniem profilu niż po tym, jak ktoś zauważy brak tras.