Jak utrzymać czytelność planu adresowania IPv6 dla VPN po roku
Czytelny plan mówi, który prefiks należy do której lokalizacji i jak wracają odpowiedzi. Zapisz role, notację, delegację i trasy powrotne obok każdego wpisu.
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.
| Entry | Fields to record | Why a reviewer needs it |
|---|---|---|
| Endpoint addresses | Prefix, owning side, session initiator | Firewall rules and peer config both read it |
| Tunnel interfaces | Prefix and length, next hop, interface name | Shows the path a packet actually takes |
| Client allocations | Pool range, size, distributing component | Shows room left before a redesign |
| Downstream networks | Prefix, site label, return route | Explains 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.