Як розрахувати адресний простір для VPN між майданчиками
Транспортні кінцеві точки, внутрішні канали, захищені локальні мережі та підмережі шлюзу — це чотири окремі бюджети. Кожен розраховуйте з топології, а не з кількості пристроїв.
Запитайте, якого розміру має бути підмережа VPN, і чесна відповідь буде такою: у питанні можуть ховатися чотири різні підмережі. VPN майданчика може включати транспортні кінцеві точки, пронумеровані тунельні канали, префікси захищеної локальної мережі та, на керованих шлюзах, інфраструктурну підмережу, яку резервує провайдер. У конкретному проєкті існують лише одна-дві з них. Розраховувати їх за кількістю офісних пристроїв — це шлях до плану з /24, який нікого не влаштує.
Назвіть чотири ролі, перш ніж будь-що виділяти
Транспортні кінцеві точки — це адреси, які два шлюзи використовують, щоб досягти один одного через інтернет або виділений канал, і їхня кількість визначається моделлю шлюзу та резервування, а не локальною мережею. Внутрішні тунельні канали існують лише там, де проєкт нумерує інтерфейс «точка-точка», чого конфігурація IPsec на основі політик зазвичай не робить. Захищені префікси — це реальні офісні мережі або мережі VPC, які мають бути маршрутизованими, а зарезервована провайдером підмережа належить керованому сервісу.
Проведіть інвентаризацію того, що вже є, перш ніж щось додавати, бо дорога помилка тут — повторно використати префікс, який уже маршрутизується в іншому місці. Старого тунелю з пілотного проєкту достатньо, щоб зіпсувати план. Запишіть інвентаризацію з датами, бо пам’ять про виведений з експлуатації канал живе довше за сам канал.
ip -br addr show ip route show | head -40
Ці дві команди дають локальну картину під’єднаних мереж і маршрутів, які досягають усього за їхніми межами. Повторіть інвентаризацію на кожному майданчику, бо план, побудований за виводом одного майданчика, зіткнеться з виводом наступного. Зберіть виводи, перш ніж виділяти хоча б один блок.
Рахуйте канали й топологію, а не пристрої
Проєкт із вісьмома сусідствами «точка-точка» витрачає вісім блоків, а не один. За /30 кожен блок витрачає чотири адреси, щоб з’єднати два вузли, тож план несе тридцять дві адреси на шістнадцять придатних кінцевих точок, і саме цю цифру має витримати бюджет. Платформа, що підтримує канали /31, витрачає половину, але лише коли обидва кінці та сервіс згодні з такою моделлю. Округляйте бюджет угору, а не вниз, бо зменшити блок пізніше означає перенумерувати робочі канали.
Обмеження провайдера важливіші за загальну практику. Задокументований внутрішній діапазон тунелю може вимагати /30 навіть там, де /31 працює на ваших маршрутизаторах, а керований шлюз може вимагати конкретної маски для своєї підмережі. Прочитайте вимогу сервісу, перш ніж застосовувати правило, позичене з іншої платформи.
Багатоточкове накладення знову змінює арифметику: одна адреса на шлюз, а досяжність між ними забезпечує накладення. Вирішіть, яку топологію реалізація справді використовує, перш ніж множити майданчики на розмір блоку.
Зростання заслуговує на окремий рядок у плані. Зарезервувати зв’язний інфраструктурний діапазон розумно, як і записати, які менші виділення лежать усередині нього, щоб наступний інженер не прочитав резервування як один широкомовний домен.
Тримайте підмережу шлюзу поза пулом локальної мережі
Інфраструктура керованого шлюзу — не пул клієнтів. Адреси в зарезервованій підмережі шлюзу розміщують власні компоненти сервісу, і віддалені працівники ніколи з них не беруть. Розраховувати цю підмережу за кількістю користувачів — категоріальна помилка, яка або марнує великий діапазон, або змушує шлюз голодувати.
Те саме стосується діапазонів тунелів у хмарних VPN-підключеннях, де провайдер виділяє невеликий внутрішній діапазон на кожен тунель для власних потреб. Цей діапазон — не місце, де живуть ваші сервери філії, і він не ваш, щоб його роздавати.
aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table
Перелік зовнішніх адрес підтверджує, що виділив провайдер і який резервний тунель зараз активний. Це швидше, ніж читати проєктний документ, написаний до того, як підключення з’явилося.
Записуйте роль, власника та зростання для кожного префікса
План, який переживає зіткнення з експлуатацією, зазначає для кожного префікса, яку роль він грає, хто виділяє дальній кінець і скільки запасу він має. Без поля власника дві команди виділяють ту саму /24 в одному кварталі, і зіткнення проявляється лише коли тунель піднімається.
Тримайте ці діапазони далі від домашніх і філіальних префіксів, що надходять через інші тунелі, бо перекривний простір — звичайна причина того, що з’єднання між майданчиками успішно узгоджується, а потім не пропускає трафік.
Виділення внутрішніх адрес каналу не анонсує локальні мережі за ними. Маршрути або селектори трафіку, зворотні шляхи та правила доступу — окремі робочі пункти, і план має казати це, а не натякати, що нумерований інтерфейс виконає маршрутизацію за вас.