Dokumentacja split-tunnelu wymaga reguły DNS obok każdej trasy
Trasa decyduje po adresie, resolver decyduje po nazwie. Udokumentuj oba selektory dla każdego przepływu, każdy z jednym testem, inaczej notatka zawiedzie, gdy DNS się przesunie.
Notatka o split-tunnelu mówiąca "ruch biurowy idzie przez VPN" udokumentowała jedną decyzję i zasugerowała trzy inne. Na warstwie pakietów tablica routingu wybiera interfejs po adresie docelowym; na warstwie nazw resolver wybiera serwer po zapytaniu, a te dwa wybory są dokonywane niezależnie. Dlatego poprawnie udokumentowany prefiks nadal może dać maszynę, która rozwiązuje nazwę wewnętrzną na adres publiczny albo nie rozwiązuje nic, podczas gdy trasa wygląda idealnie.
Dwa selektory, jedna próba połączenia
Gdy aplikacja łączy się z files.corp.example, przed powstaniem pakietu odbywają się dwa wyszukiwania. Resolver decyduje, który serwer otrzyma zapytanie, używając domen wyszukiwania, domen routingu dla każdego łącza lub jawnej reguły profilu. Następnie tablica routingu decyduje, dokąd trafi wynikowy adres, używając najdłuższego dopasowania prefiksu do celu.
Nic nie łączy tych dwóch decyzji. Strefa prywatna może odpowiedzieć 10.20.4.11, podczas gdy tablica routingu wysyła 10.20.0.0/16 do tunelu, i połączenie działa. Odwróć którąkolwiek, a zawiedzie w sposób, który wygląda jak druga: poprawna polityka DNS plus brakująca trasa daje rozwiązaną nazwę i przekroczenie czasu, a poprawna trasa plus publiczny resolver daje adres, który czysto routuje się w niewłaściwe miejsce.
DNS z podzielonym horyzontem czyni to ostrzejszym. Ta sama nazwa może zwrócić adres prywatny z resolvera wewnętrznego i publiczny z tego skierowanego do internetu, więc notatka rejestrująca tylko prefiks nie przewidzi, którego adresu klient faktycznie użyje. Zapisz ścieżkę resolvera, inaczej adres jest zgadywaniem.
Co pomija notatka tylko o trasie
Zapis tylko o trasie jest bezużyteczny dla najczęstszej awarii split-tunnelu: nazw. Użytkownik zgłasza, że intranet się nie ładuje, tunel działa, a prefiks jest obecny. Kto przejmie zgłoszenie, nie ma zapisu, który resolver powinien odpowiedzieć, nie ma sposobu odróżnić złego sufiksu wyszukiwania od zablokowanego serwera i nie ma punktu odniesienia do porównania.
Drugie pominięcie to lista wyjątków. Projekt split-tunnelu jest definiowany zarówno przez to, co zostaje poza tunelem, jak i przez to, co do niego wchodzi, a wykluczone zakresy zwykle psują się pierwsze, bo bardziej szczegółowa trasa lokalna lub filtr po stronie klienta może nadpisać intencję bez dotykania profilu.
Trzecie to dalsza strona tunelu. Trasa klienta tylko kładzie pakiet na drucie; brama nadal musi go przekazać i mieć drogę powrotną. Przewodnik strongSwan po przekazywaniu przypomina, że reguły przekazywania i zapory na bramie są częścią funkcji, a nie częścią hydrauliki, którą można zakładać.
Pola, które czynią notatkę wykonalną
Jeden wiersz na przepływ, a przepływ to cel plus nazwa plus właściciel. To pola, które przetrwają zetknięcie z realnym incydentem:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Wiersz "gdzie to mieszka" jest tym, który ludzie pomijają. Prefiks wypychany przez serwer, trasa dodana przez profil klienta i trasa wpisana w powłoce różnią się tym, kto może je zmienić i czy przetrwają ponowne połączenie. Bez tego pola następny inżynier nie wie, którą z trzech widzi.
Jeden test na regułę, nie jeden na tunel
Każdy wiersz wymaga dwóch nieszkodliwych kontroli: jednej ćwiczącej trasę i jednej ćwiczącej nazwę. Dla trasy poproś o coś, co musi przejść przez tunel, i potwierdź ścieżkę, a nie osiągalność, na przykład tracert -d 10.20.4.11 w Windows lub ip route get 10.20.4.11 w Linux. Dla nazwy odpytaj nazwę prywatną i zapisz, który serwer odpowiedział, używając resolvectl query files.corp.example lub dig files.corp.example wobec resolvera wskazanego w notatce.
Dodaj także oczekiwanie negatywne: co powinno się stać, gdy tunel jest wyłączony. Wykluczona aplikacja na urządzeniu Android lub iOS z włączonym blokowaniem bez VPN może nie mieć żadnej łączności, a klient desktopowy może zostawić tę samą aplikację działającą, gdy tunel łączy się ponownie. Zapisanie zamierzonej odpowiedzi zamienia "VPN zepsuł moją aplikację" w sprawdzalne twierdzenie.
Trzymaj zapis razem z konfiguracją
Przechowuj notatkę obok profilu, który opisuje, i wersjonuj ją z tym profilem. Dokument w wiki, którego nikt nie aktualizuje, jest plotką; tabelę w tym samym repozytorium co wypychane trasy i polityka resolvera można przejrzeć w tej samej zmianie.
Gdy coś się zepsuje, porównaj zastosowaną trasę i efektywny resolver z zapisem, zanim dodasz kolejny wyjątek. Dwie z trzech częstych przyczyn — stara reguła przestrzeni nazw i proces pomocniczy poza polityką aplikacji — wyglądają dokładnie jak awaria VPN i są niewidoczne, jeśli notatka wymienia tylko prefiksy.
Zanim uznasz notatkę za gotową, potwierdź, że pisemnie odpowiada na to: który prefiks, dla której rodziny adresów; która prywatna przestrzeń nazw, przez który resolver obsługiwana; które nazwy celowo pozostają publiczne; gdzie skonfigurowano każdą regułę i kto jest jej właścicielem; oraz jedyne polecenie dowodzące trasy i to dowodzące nazwy. Jeśli czegokolwiek brakuje, następny incydent będzie diagnozowany od zera.