Як захаваць чытэльнасць плана адрасоў 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 і правілы брандмаўэра, якія мусяць змяніцца ў тым самым акне, бо абнаўленне прэфікса, што спыняецца на маршрутызатары, зроблена напалову.
Пасля змены дабярыцеся да рэсурсу за кожнай мяжой, якую закранула змена, перш чым рэдагаваць дакумент. План, які апісвае сетку мінулага месяца, горшы за адсутнасць плана, бо людзі яму давяраюць. Трымайце адкліканыя размеркаванні ў спісе з датай знікнення, каб ніхто выпадкова не выдаў іх зноў. Сакрэты застаюцца па-за файлам; план тлумачыць сетку, а не адкрывае яе.
Захоўвайце план там, дзе змены праходзяць праверку, побач з канфігам, які ён апісвае. Дакумент, які ніхто не перачытвае, гніе хутчэй за сетку, якую ён адлюстроўвае.