Dwa pytania decydują, czy plan adresowania zasługuje na swoje miejsce: który prefiks należy do której lokalizacji i jak odpowiedź wydostaje się z tej lokalizacji. Odpowiedz na oba za jednym razem, a opiekun może zmienić peera, nie wypytując nikogo. Wszystko inne w dokumencie istnieje po to, by wspierać te dwie odpowiedzi. To, co nie wspiera żadnej z nich, jest ozdobą.

Na co czytelnik musi odpowiedzieć, zanim dotknie peera

Kompresja sprawia, że adresy wyglądają schludnie, a schludność nie jest strukturą. Struktura to wiedza, który zakres dostawca delegował, który wybrałeś, który jest pulą klientów i który stoi za lokalizacją.

Pisz dla kolegi, który dołączy w przyszłym kwartale i będzie musiał dodać drugą lokalizację. Nic na stronie nie powie mu, skąd pochodzi prefiks, jeśli wpis tego nie zrobi. Pominięcie tego sprawia, że pierwsza zmiana zamienia się w archeologię.

Co musi nieść każdy wiersz planu

Cztery pola czynią wpis weryfikowalnym: długość prefiksu, jego właściciel, dokąd trafia ruch dalej i który komponent rozdaje wartość. Zestaw je z działającą konfiguracją, a każda niezgodność wychodzi sama. Następny skok skierowany do tunelu usuniętego w zeszłym miesiącu wygląda od razu źle zamiast wtapiać się w tło.

Trzymaj role w osobnych wierszach, nawet gdy dwie z nich dzielą dziś ten sam prefiks. Scalanie zamienia późniejsze rozdzielenie w coś, co czyta się jak nowa alokacja, a nie poprawka.

EntryFields to recordWhy a reviewer needs it
Endpoint addressesPrefix, owning side, session initiatorFirewall rules and peer config both read it
Tunnel interfacesPrefix and length, next hop, interface nameShows the path a packet actually takes
Client allocationsPool range, size, distributing componentShows room left before a redesign
Downstream networksPrefix, site label, return routeExplains a reply that never arrives

Gdzie rozchodzą się tekst kanoniczny i składnia konfiguracji

RFC 5952 ustala jedną formę tekstową adresu: małe litery, bez zer wiodących i najdłuższy ciąg grup zerowych skompresowany dokładnie raz. Używaj jej w notatkach, zgłoszeniach i rejestrach zmian, aby dwa dokumenty porównywały się bez konwersji. Czytelnicy, którzy napotkają dwie pisownie tego samego adresu, zaczynają szukać różnicy, której nie ma. Spójność jest tu tania i usuwa całą klasę fałszywych alarmów.

Pliki konfiguracyjne podlegają własnym regułom i nie są to reguły czytelności. Adres sparowany z portem wymaga nawiasów, nawet gdy sam adres ich nie wymaga, a kopia z notatki do pliku konfiguracyjnego gubi to rozróżnienie bez ostrzeżenia. Nazwij formę używaną przez każde pole, inaczej plan powoduje dokładnie ten błąd przepisywania, któremu miał zapobiec.

Dwie notacje są w porządku, o ile każda jest oznaczona. To nieoznaczone mieszanie zaprasza błąd.

Gdzie pojawiają się nakładające się zakresy i brakujące trasy powrotne

Nakładanie się przeżywa inne błędy, bo nic nie wygląda źle, dopóki dwie lokalizacje nie odpowiadają za ten sam zakres. Oznacz lokalizację i generuj lokalnie unikalne prefiksy udokumentowaną procedurą zamiast kopiować przykład.

Lista klientów nigdy nie wyjaśnia, w którą stronę podróżuje odpowiedź. Zapisz ścieżkę powrotną bramy LAN obok zakresu peera, który niesie tunel, a wpis wyjaśni zdalną podsieć, która odbiera żądania i milczy. Uruchom poniższe kontrole na maszynie i porównaj je z wpisem. Plan, który przeczy ip -6 route, to plan, którego ludzie przestają czytać.

ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0

Osiągalność nie jest autoryzacją, a prefiks nigdy nie oznacza polityki. Zapisz zamierzony dostęp obok trasy, której dotyczy. W przeciwnym razie następny czytelnik potraktuje adres w planie jako pozwolenie na dotarcie do każdej usługi za nim.

Jak plan przetrwa trzecią lokalizację

Oznacz każdy prefiks jako delegowany, lokalnie przydzielony lub trasowany w inny sposób. Dla wszystkiego, co może się przesunąć, nazwij proces, który to robi. Następnie wypisz rekordy DNS i reguły zapory, które muszą się zmienić w tym samym oknie, bo aktualizacja prefiksu, która zatrzymuje się na routerze, jest zrobiona do połowy.

Po zmianie dotrzyj do zasobu za każdą granicą, którą zmiana dotknęła, zanim edytujesz dokument. Plan opisujący sieć z zeszłego miesiąca jest gorszy niż żaden, ponieważ ludzie mu ufają. Trzymaj wycofane przydziały na liście z datą, w której zniknęły, żeby nikt przypadkiem nie wydał ich ponownie. Sekrety zostają poza plikiem; plan wyjaśnia sieć, nie otwiera jej.

Przechowuj plan tam, gdzie zmiany są przeglądane, obok konfiguracji, którą opisuje. Dokument, którego nikt nie czyta ponownie, gnije szybciej niż sieć, którą mapuje.

Powiązane artykuły