Как сохранить читаемость плана адресации IPv6 для VPN спустя год
Читаемый план говорит, какой префикс относится к какой площадке и как возвращаются ответы. Записывайте роли, нотацию, делегирование и обратные маршруты рядом с каждой записью.
Два вопроса решают, заслуживает ли план адресации своего места: какой префикс относится к какой площадке и как ответ выходит из этой площадки. Ответьте на оба за один раз, и сопровождающий сможет изменить пир, никого не допрашивая. Всё остальное в документе существует, чтобы поддерживать эти два ответа. То, что не поддерживает ни одного, — украшение.
На что читатель должен ответить, прежде чем трогать пир
Сжатие делает адреса аккуратными, а аккуратность — не структура. Структура — это знание, какой диапазон делегировал провайдер, какой выбрали вы, какой является пулом клиентов и какой находится за площадкой.
Пишите для коллеги, который придёт в следующем квартале и должен добавить вторую площадку. Ничто на странице не скажет, откуда взялся префикс, если запись этого не делает. Пропустите это, и первое изменение превратится в археологию.
Что должна нести каждая строка плана
Четыре поля делают запись проверяемой: длина префикса, владелец, куда уходит трафик дальше и какой компонент выдаёт значение. Сопоставьте их с работающей конфигурацией, и любое расхождение всплывёт само. Следующий переход, нацеленный на туннель, удалённый в прошлом месяце, выглядит неверным сразу, а не сливается с остальным.
Держите роли в отдельных строках, даже когда две из них сегодня делят один префикс. Их объединение превращает последующее разделение в нечто читающееся как новое выделение, а не как исправление.
| 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 |
Где расходятся канонический текст и синтаксис конфигурации
RFC 5952 закрепляет единственную текстовую форму адреса: строчные буквы, без ведущих нулей и самая длинная последовательность нулевых групп, сжатая ровно один раз. Используйте её в заметках, заявках и журналах изменений, чтобы два документа сравнивались без преобразования. Читатели, встретившие два написания одного адреса, начинают искать разницу, которой нет. Последовательность здесь дешева и убирает целый класс ложных тревог.
Файлы конфигурации подчиняются своим правилам, и это не правила читаемости. Адрес в паре с портом требует скобок даже тогда, когда голый адрес не требует, а копия из заметки в файл конфигурации теряет это различие без предупреждения. Назовите форму, которую использует каждое поле, иначе план вызовет именно ту ошибку переноса, которую должен был предотвратить.
Две нотации допустимы, пока каждая помечена. Именно непомеченное смешение и приглашает ошибку.
Где появляются перекрывающиеся диапазоны и отсутствующие обратные маршруты
Перекрытие переживает другие ошибки, потому что ничего не выглядит неправильным, пока две площадки не отвечают за один диапазон. Пометьте площадку и генерируйте локально уникальные префиксы документированной процедурой, а не копируя пример.
Список клиентов никогда не объясняет, в какую сторону идёт ответ. Запишите обратный путь шлюза LAN рядом с диапазоном пиров, который несёт туннель, и запись объяснит удалённую подсеть, которая получает запросы и молчит. Запустите проверки ниже на машине и сравните их с записью. План, который противоречит ip -6 route, — это план, который люди перестают читать.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0Доступность — не разрешение, и префикс никогда не подразумевает политику. Запишите предполагаемый доступ рядом с маршрутом, к которому он относится. Иначе следующий читатель примет адрес в плане за разрешение добраться до каждой службы за ним.
Как план переживает третью площадку
Пометьте каждый префикс как делегированный, назначенный локально или маршрутизируемый иначе. Для всего, что может двигаться, назовите процесс, который это делает. Затем перечислите записи DNS и правила межсетевого экрана, которые должны измениться в том же окне, потому что обновление префикса, останавливающееся на маршрутизаторе, сделано наполовину.
После изменения дойдите до ресурса за каждой границей, которую затронуло изменение, прежде чем править документ. План, описывающий сеть прошлого месяца, хуже отсутствующего, потому что люди ему доверяют. Держите отозванные выделения в списке с датой, когда они исчезли, чтобы никто случайно не выдал их снова. Секреты остаются вне файла; план объясняет сеть, а не открывает её.
Храните план там, где изменения проходят проверку, рядом с конфигурацией, которую он описывает. Документ, который никто не перечитывает, гниёт быстрее, чем сеть, которую он отображает.