Co zapisywać dla VPN między oddziałami: selektory i zakres

Pół roku po wdrożeniu tunelu nowa podsieć przestaje pasować do polityki, a jedyny dokument na udziale mówi tylko „VPN biurowy”. To właśnie awaria, której zapobiega zapis selektorów, i jest ona konkretna: zbiór adresów się zmienił, a dokumentacja nie. Napisać ten zapis poprawnie znaczy wiedzieć, który z kilku zbiorów adresów opisujesz, i zapisać ten, który druga strona naprawdę egzekwuje, a nie ten, który skonfigurowałeś.

Skonfigurowane to nie wynegocjowane

W tunelu IPsec opartym na politykach każda strona proponuje selektory ruchu: zakresy źródła i celu dla asocjacji podrzędnej. Strona odpowiadająca może zawęzić tę propozycję, więc zainstalowana asocjacja może obejmować mniej, niż wymienia konfiguracja. Zapis, który kopiuje konfigurację, opisuje zamiar, a nie bieżący zakres ochrony. Te dwie rzeczy rozjeżdżają się po cichu i nic na stronie stanu tunelu na to nie wskazuje.

Trzymaj obie kolumny wraz z datą obserwacji. Skonfigurowany selektor to to, co zamierzałeś; wynegocjowany to to, co jądro egzekwuje teraz. Gdy się różnią, ta różnica tłumaczy zaskakującą awarię znacznie częściej niż błąd routingu.

Jedna asocjacja nie reprezentuje też każdej skonfigurowanej pary. Tunel z kilkoma kombinacjami selektorów może skończyć z kilkoma asocjacjami podrzędnymi, a zapis wymieniający jedną z nich to niepełny spis. Wymieniaj je zamiast je streszczać.

Tunele oparte na trasach wybierają inaczej

Przy interfejsie opartym na trasach o tym, co wchodzi do tunelu, decyduje tablica routingu, a selektory mogą być celowo szerokie. To uzasadniona konstrukcja, a nie niedbalstwo, i zapis musi to tak opisywać. Zapisz trasę, interfejs, na który wskazuje, oraz politykę zapory ograniczającą dostępne usługi. Zakres ochrony jest szeroki celowo, a zawężenie wykonuje zakres usług.

Skopiowanie szablonu opartego na politykach na tunel oparty na trasach daje dokument opisujący mechanizm, którego wdrożenie nie używa. Kolejny inżynier szuka wtedy selektorów, których nigdy nie miało tam być, i uznaje, że tunel jest źle skonfigurowany, gdy jest tylko źle opisany.

Tłumaczenie adresów należy do tej samej tabeli

Gdy NAT pokazuje drugiej stronie inny zakres, zapisuj prefiksy oryginalne i przetłumaczone razem. Wskaż etap, na którym selektory i reguły dostępu je dopasowują, bo kolejność decyduje o tym, czy strona odległa kiedykolwiek zobaczy zapisany adres. Tabela z tylko jednym z dwóch zakresów jest gorsza niż brak tabeli, bo wygląda na kompletną.

To ten szczegół psuje działający tunel po zmianie NAT: selektor nadal pasuje do oryginalnego prefiksu, druga strona otrzymuje teraz przetłumaczony, a jej trasa powrotna wskazuje adres, który już nie istnieje. Nic nie loguje błędu w chwili, gdy przestają się zgadzać.

Prywatny DNS należy w to samo miejsce. Nazwa, która rozwiązuje się na adres nieużyteczny z danej lokalizacji, to błąd w dokumentacji z dołączonym zgłoszeniem do wsparcia, i wina spadnie na tunel.

Dołącz wymaganie usługowe

Chroniony zakres to nie lista uprawnień. Zapisz, które usługi mają być osiągalne z którego źródła i kto jest właścicielem aplikacji za nimi. Te dwa pola odpowiadają na różne pytania, a ich mieszanie sprawia, że przegląd bezpieczeństwa kończy się sporem o routing zamiast o dostęp.

Potem wskaż administratora sieci, który utrzymuje tę regułę. Spis selektorów bez właściciela po cichu się starzeje, a starego nie da się odróżnić od błędnego, gdy tunel padnie o drugiej w nocy. Właściciel to także osoba, która może potwierdzić, że zmiana była zamierzona.

Zamień zapis w plan testów

Dla każdej wymaganej ścieżki wybierz reprezentatywny host źródłowy i docelowy i zanotuj oczekiwaną trasę, usługę i bramę odpowiedzi. To zamienia dokument w plan testów, a nie w opis. Odczytaj aktywną asocjację poniższym poleceniem i porównaj ją z wynegocjowanym wierszem, który zapisałeś.

swanctl --list-sas

Szkielet z pięciu wierszy zwykle wystarcza, by zapis pozostał uczciwy. Poniższa wersja mieści się w zgłoszeniu zmiany bez skracania:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ping tylko do bramy nie jest testem odbiorczym. Nigdy nie ćwiczy ścieżki tranzytowej, więc może przechodzić, gdy każdy przekazywany przepływ zawodzi. Testuj z hosta po jednej stronie do usługi po drugiej i potwierdź, że odpowiedź przychodzi przez tunel. Jeśli przechodzi tylko ping, zapis właśnie znalazł problem z przekazywaniem, któremu miał zapobiec. Dokumentacja strongSwan o przekazywaniu wyjaśnia, jak selektory, trasy i przekazywanie współdziałają na węźle Linux.