Как да запазим четимостта на 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 записите и правилата на защитната стена, които трябва да се променят в същия прозорец, защото обновяване на префикс, което спира на рутера, е наполовина готово.
След промяна достигнете до ресурс зад всяка граница, която промяната е засегнала, преди да редактирате документа. План, който описва мрежата от миналия месец, е по-лош от никакъв, защото хората му вярват. Дръжте оттеглените разпределения в списък с датата, на която са изчезнали, за да не ги издаде някой отново по погрешка. Тайните остават извън файла; планът обяснява мрежата, не я отваря.
Съхранявайте плана там, където промените се преглеждат, до конфигурацията, която описва. Документ, който никой не препрочита, гние по-бързо от мрежата, която картографира.