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

Яким має бути розмір підмережі VPN, відповіді немає, доки не названо, які адреси ви рахуєте. В одному проєкті це два кінці нумерованого тунельного з’єднання, в іншому — локальна мережа офісу за тунелем на основі політик, у третьому — резервована інфраструктура керованого шлюзу. Три об’єкти, три бюджети, і більшість помилок у розмірах виникає через заповнення одного стовпця числом з іншого.

Чотири ролі, чотири різні питання

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

Лише третій із них пов’язаний з тим, скільки ноутбуків є в офісі. Саме це єдине змішування пояснює більшість суперечок.

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

Підрахунок блоків: скільки насправді коштує /30

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

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

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

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

Підмережа керованого шлюзу — не пул клієнтів

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

Читайте вимогу провайдера як фіксовані витрати, так само як ви поставилися б до одиниці стійки. Вона не входить до бюджету захищеного префікса.

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

Задокументуйте план, щоб він пережив другий майданчик

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

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

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