Zapisz ścieżkę pakietu, zanim skonfigurujesz VPN

Większość wdrożeń VPN zaczyna się od klienta i profilu, a gdy tunel stoi, nikt nie potrafi powiedzieć, który pakiet miał go przejść. Pierwsza strona pracy jest tańsza niż trzecia godzina debugowania: opisz jedno zamierzone połączenie od końca do końca, na papierze, zanim powstanie plik konfiguracyjny. Ćwiczenie zwykle rozstrzyga pytanie, którego jeszcze nie zadałeś, na przykład czy wymaganiem jest wyjście do internetu, zdalny dostęp do podsieci czy łącze między dwiema lokalizacjami.

Jedno połączenie wystarczy na początek. Trzy strony topologii zwykle ukrywają tę samą brakującą odpowiedź.

Opisz jedno żądanie, nie diagram

Zacznij od nadawcy: zakres adresów, rodzina adresów i aplikacja, która tworzy ruch. Następnie nazwij prefiks celu i usługę na nim, aż do portu i protokołu, ponieważ reguła, która dopuszcza podsieć, ale nie usługę, jest regułą, która nic nie robi. Dwa adresy to cała istota, a wszystko poniżej to mechanizm, który musi się z nimi zgadzać.

Wypisz ścieżkę po kolei: łącze fizyczne, punkt końcowy VPN po każdej stronie, sam tunel i sieć za nim. Zapisz nazwy interfejsów, jeśli je znasz, bo właśnie ten szczegół zamienia opis w coś, co później możesz porównać z tabelą routingu. Dodaj adres, którego każdy interfejs używa po stronie tunelu. Bez tych dwóch faktów nikt inny nie sprawdzi zapisu względem urządzenia.

Teraz nazwij jedno zamierzone połączenie w jednym zdaniu na górze strony. Jeśli to zdanie potrzebuje słowa lub, masz dwa projekty i powinieneś potraktować je osobno.

Śledź odpowiedź przed żądaniem

Ścieżka, która opisuje tylko kierunek wychodzący, to połowa dokumentu. Śledź odpowiedź z powrotem i ustal, które urządzenie zna zakres nadawcy, czy tłumaczenie zmienia źródło na wyjściu i gdzie pakiet powrotny ma wejść. Właśnie na odpowiedzi większość wdrożeń zawodzi, bo żądanie łatwo zaobserwować, a odpowiedź nie.

Wyraźnie odnotuj każde tłumaczenie adresów, w tym gdzie się odbywa i co potem widzi drugi koniec. Para, która loguje jeden adres i routuje do innego, opisuje dwa różne projekty.

Rozwiązywanie nazw traktuj jako osobną wymianę, a nie część trasy aplikacji. Wewnętrzny rekord może wymagać resolvera osiągalnego tylko przez tunel, a zapis ścieżki kończący się na prefiksie aplikacji tego nie ujawni. To samo dotyczy każdej walidacji certyfikatu, która zależy od dotarcia do wewnętrznego urzędu.

Nadaj każdej decyzji właściciela

Dla każdej trasy, reguły zapory, selektora i poświadczenia zapisz, która konfiguracja je trzyma i która osoba może je zmienić. Właściciel w każdym wierszu to coś, co pozwala dokumentowi przetrwać pierwsze żądanie zmiany, bo alternatywą jest dokument opisujący intencję i sieć opisująca historię.

Uważaj na dwóch właścicieli jednej wartości domyślnej. Skrypt klienta i menedżer sieci mogą oba instalować trasy, nie wiedząc o sobie nawzajem, a zezwolenie na nasłuch na bramie to nie to samo zezwolenie co przekazywanie. Oba przypadki dają zapis ścieżki poprawny na papierze i błędny na kablu.

Gdy wartość ustala dostawca, a nie ty, powiedz to w tym samym wierszu. Prefiks delegowany przez firmę hostingową ma inny proces zmiany niż ten, który wybrałeś sam. Ta notatka oszczędza następnemu inżynierowi zgłoszenia do pomocy technicznej podczas incydentu. Wyjaśnia też, dlaczego zatwierdzona przez ciebie zmiana nie miała żadnego efektu.

Opisz, co się psuje i jak się podnosisz

Dla każdego etapu ścieżki podaj, co się zatrzymuje, gdy tunel znika, i które połączenie wychodzące musi pozostać osiągalne, żebyś mógł to naprawić. Projekt, który traci dostęp administracyjny razem z tunelem, to projekt wymagający wizyty na miejscu.

Pełny tunel i tunel dzielony należą do tej strony jako wyraźny wybór, a nie pole wyboru, bo zmieniają zarówno tryb awarii, jak i ścieżkę odzyskiwania.

Nazwij nieszkodliwy test dla każdego etapu

Osiągalność punktu końcowego, zestawienie tunelu, adres prywatny, nazwa prywatna i uprawnienie aplikacji to pięć różnych obserwacji, a każda potrzebuje testu, którego nie można pomylić z innym. Ping do bramy dowodzi co najwyżej dwóch pierwszych. Połączenie do portu aplikacji dowodzi czwartej i piątej tylko wtedy, gdy nazwa została rozwiązana przez zamierzony resolver.

Zapisz test obok etapu, który obejmuje, wraz z poleceniem i oczekiwanym wyjściem. Strona precyzyjnych ścieżek bije stronę poleceń, która nigdy nie mówi, na które pakiety miały wpływać.