Сплануйте приватні діапазони адрес VPN до того, як майданчики зіткнуться

Два майданчики, які обидва використовують 192.168.1.0/24, можуть кожен виходити в інтернет і при цьому не досягати один одного. Шлюз не видає помилку; він встановлює один маршрут для цього префікса й надсилає кожен пакет тому партнеру, який запросив його першим. Ніщо в рукостисканні, списку шифрів чи метриці інтерфейсу не каже, який партнер помиляється. Планування адрес — та частина проєкту, яка вирішує це до чийогось підключення.

Проведіть інвентаризацію кожного простору, який має бути доступним

Запишіть діапазони, які треба маршрутизувати, а не лише ті, що ви налаштовуєте. Це локальні мережі майданчиків, пули клієнтів VPN, хмарні підмережі, мережі керування та позасмугові мережі, лабораторні сегменти й мережі, з яких користувачі зазвичай підключаються з дому. Споживчий маршрутизатор, що постачається як 192.168.1.0/24, не є гіпотетичним, і той самий префікс трапляється в готелях і конференц-центрах. Інвентаризація — це таблиця префікса, власника й призначення, і це єдиний артефакт, який не дає видати той самий діапазон двічі.

Додайте префікси, які ви очікуєте протягом наступного року, бо план, що покриває лише сьогодні, руйнується на першому новому майданчику. Позначте в кожному рядку, хто може його змінити, а не лише хто ним володіє.

Саме повторне використання робить це складним: приватний простір скінченний, і кожна організація вважає 10.0.0.0/8 своїм. План не може обіцяти, що майбутня гостьова мережа не опиниться на одному з ваших префіксів, тому проєкт має сказати, що станеться, коли це станеться. Два правила роблять більшу частину роботи. Помістіть пули клієнтів в один безперервний блок, який можна підсумувати, і ніколи не виділяйте діапазон, який уже маршрутизує інша команда. Усе інше — запис, який хтось підтримує в актуальному стані.

Чому перекриття перемагає таблицю маршрутизації

Маршрут — це префікс плюс наступний стрибок, а пересилання обирає найдовший відповідний префікс. Коли два партнери обидва вимагають той самий 192.168.1.0/24, у таблиці є один запис для нього, тож трафік обох майданчиків виходить через один і той самий тунель. Другий майданчик не налаштований неправильно; він недоступний, бо перший відповідає за ті самі адреси. Жодна метрика не може їх розділити, бо збіг відбувається до того, як метрики беруться до уваги.

Відмова асиметрична, і її легко прочитати неправильно. Вузли майданчика A досягають шлюзу й деяких служб, а вузли майданчика B не відповідають ні на що, і журнал показує справний тунель в обидва боки. Ця картина — колізія адрес, а не збій автентифікації чи міжмережевого екрана, і для її підтвердження потрібен один дамп таблиці, звірений з інвентаризацією.

Свідомо задайте розмір пулу клієнтів і діапазонів майданчиків

Пул клієнтів VPN — це діапазон, з якого шлюз видає по одній адресі, тому його розмір обмежує одночасність. /24 вміщає 254 придатні адреси, що щедро для невеликої команди й тісно для філії, яка запускає контейнери; /22 нічого не коштує додатково в приватному просторі й знімає суперечку. Тримайте пул безперервним і осторонь від кожної локальної мережі майданчика, щоб зведений маршрут до клієнтів ніколи не проковтнув майданчик. Резервуйте діапазон навіть тоді, коли пул порожній, бо незаписаний діапазон — той, який виділить наступний інженер.

Майданчики отримують діапазони, розраховані на очікувані вузли плюс зростання, вирівняні по межі, що чисто підсумовується. Навмисні проміжки між виділеннями нічого не коштують і купують місце для подальшої агрегації.

Потім перевірте напрямок, який люди забувають: зворотний шлях. Кожному маршрутизатору майданчика потрібен маршрут до пулу клієнтів, а концентратору потрібен маршрут до кожного префікса майданчика, який він обслуговує. Охайна таблиця префіксів без шляху назад до пулу — все ще зламаний проєкт, і симптом — одностороннє з’єднання, яке ні на що не відповідає. Тримайте обидва напрямки в одній таблиці й переглядайте її щоразу, коли додається майданчик.

Трансляція та перенумерація вирішують різні завдання

Коли перекриття вже існує, є два чесні варіанти й один нечесний. Перенумерація назавжди прибирає колізію й коштує вікна обслуговування плюс кожної забутої жорстко заданої адреси. Трансляція адрес відображає приватний діапазон однієї сторони в інший діапазон на краю тунелю, що залишає обидва майданчики недоторканими, але додає стан, ламає протоколи, які вбудовують адреси, і ускладнює читання журналів. Нечесний варіант — маршрут до вузла до одного сервера, який проходить один тест і зазнає невдачі в усьому іншому.

Обирайте за контролем і терміном життя. Майданчик, яким ви володієте і який можете планувати, належить до шляху перенумерації; мережа партнера, до якої ви не можете доторкнутися і яка використовується для одного застосунку, — кандидат на трансляцію з документованим зіставленням. Запишіть це зіставлення, бо трансляція, що існує лише всередині файлу конфігурації, зникає в момент заміни файлу.

Тестуйте з віддаленого боку до розгортання

Тестуйте з мережі, яка не розміщує шлюз, бо власна локальна мережа шлюзу приховує більшість помилок маршрутизації. Підключіть клієнта за звичайним домашнім маршрутизатором, потім досягніть служби на кожному майданчику й однієї всередині пулу клієнтів. Перевірте й зворотний напрямок, від вузла майданчика до клієнта, бо зворотні шляхи відмовляють незалежно. Тест, який лише пінгує шлюз, доводить, що тунель піднято, і нічого більше.

Тримайте діапазони, власників і зіставлення трансляції в одному спільному записі, який наступний майданчик читає перед будь-яким виділенням. Переглядайте його при додаванні майданчика й вважайте недокументований діапазон дефектом, а не сюрпризом.

Запис — це і є результат. План, що живе в пам’яті трьох людей, руйнується за першої ж відпустки одного з них, а перекриття, знайдене в експлуатації, коштує дорожче, ніж коштувала б таблиця.