Зірка чи повнозв'язна мережа: яка топологія VPN пасує вашим майданчикам
Два працюючі тунелі — ще не топологія. Перш ніж вибрати концентратор, повнозв'язну мережу чи концентратор із кількома прямими каналами, порівняйте транзит, поведінку під час відмови та вартість змін.
Дві філії спілкуються одна з одною цілий день, а тунель між ними йде в обхід через дата-центр в іншому регіоні. Кожен запит платить за цей гак двічі, і ніхто не помічає, доки синхронізація файлів не починає здаватися неправильною. Саме тут по-справжньому починається питання про топологію: не з того, яка схема виглядає надійніше, а з того, за який шаблон трафіку ви платите. Обидва проєкти працюють, і обидва відмовляють по-різному та з різною ціною.
Спершу порахуйте кількість зв'язків між вузлами
За N майданчиків повнозв'язна мережа потребує N помножити на N мінус один, поділити на два, тунелів; концентратору потрібно N. На п'яти майданчиках це десять проти п'яти, що ще звучить здійсненно. На п'ятнадцяти це 105 проти п'ятнадцяти, і різниця вже не арифметична, а кадрова.
Кожен із цих зв'язків несе стан, яким треба керувати. В IPsec це асоціація безпеки, ідентичність, ключ або сертифікат, виявлення мертвого вузла і принаймні один маршрут на кожен віддалений префікс. У WireGuard це відкритий ключ і блок AllowedIPs на кожного партнера; дешевше на партнера, але зовсім без виявлення: новий майданчик у будь-якому разі означає зміну конфігурації на всіх наявних.
Нехай вирішує склад трафіку, а не малюнок
Якщо трафік філій — це переважно запити до центральної ERP або файлового кластера, концентратор не компроміс, а правильна форма: трафік і так хотів іти туди, а одну точку політики легше перевіряти, ніж сітку парних правил. Повнозв'язна мережа виправдовує складність, коли філії обмінюються даними між собою: реплікація між двома офісами, голос між майданчиками, спільний каталог CAD, який десяток інженерів відкриває цілий день.
Незручні випадки лежать посередині, і їх більшість. Вимірюйте, перш ніж сперечатися, а не вгадуйте з організаційної схеми.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Читайте таблицю як вирішальний аргумент, а не як правило. Три рядки з чотирьох в один бік зазвичай вирішують справу, а розбіжність означає гібрид, який більшість зрілих мереж зрештою й використовує.
Концентратору треба сказати, щоб він пересилав
Два працюючі тунелі філія — концентратор ще не створюють доступу між філіями. Концентратору потрібні увімкнене пересилання IP, маршрут у кожну мережу філії, правило брандмауера, що дозволяє транзит, і розрахований зворотний шлях; кожній філії потрібен маршрут до префіксів іншого майданчика. На Linux-концентраторі це net.ipv4.ip_forward=1 плюс ланцюжок FORWARD, який мовчки не відкидає пару, а в IPsec на основі політик — селектори трафіку, що перелічують підмережу віддаленої філії на обох кінцях. У strongSwan нотатки про пересилання охоплюють бік ядра й брандмауера, коли бракує саме цього шару. Дешевий тест: надіслати трафік з однієї філії до сервісу в іншій, спостерігаючи за лічильниками концентратора; правило, яке ніколи не зростає, означає, що неправильний порядок, а не маршрут.
Центральна політика — теж корисна частина. Філіям можна дозволити доступ до спільних сервісів, не даючи доступу одна до одної, і цю матрицю доступу варто записати явно. Відсутні маршрути — погана заміна правилу, яке людина може прочитати.
Стежте за недоладною версією: філія A маршрутизує до філії B через концентратор, концентратор маршрутизує в обидва боки, а брандмауер концентратора дозволяє нові з'єднання з A, але не з B. Перший напрямок перевіряється добре, другий зависає, і це виглядає як помилка маршрутизації, хоч нею не є.
Спершу спроєктуйте відмову, потім звичайний шлях
Один концентратор — це спільна залежність і транзитне вузьке місце, а резервування — те місце, де проєкти з концентратором зазвичай помиляються. Два концентратори означають, що кожна філія тримає два тунелі, і зворотний шлях має збігатися з вихідним; коли не збігається, брандмауер з відстеженням станів відкидає відповіді, і симптом — з'єднання, яке відкривається і потім помирає. Великі розгортання вирішують це протоколом маршрутизації поверх тунелів замість статичних префіксів: більше механізмів, але жодних здогадів. Що б ви не обрали, записуйте зворотний шлях поруч із вихідним, бо зворотна половина — та, яку ніхто не перевіряє.
Повнозв'язна мережа розподіляє цей ризик: падіння каналу одного майданчика не ізолює інші. Але вона ж множить місця, де вибір шляху може здивувати, а сеанси застосунків досі не переживають зміни шляху без сторонньої допомоги.
Жоден із проєктів сам по собі не утримує TCP-сеанс під час перемикання. Якщо застосунок не може перепідключитися, топологія — не ваша проблема.
Обирайте за вартістю змін, потім перевірте маршрути
Почніть з концентратора, бо помилитися в ньому дешевше, і додайте прямі тунелі для тих пар, чий трафік це виправдовує. Такий гібрид — не неспроможність вирішити; це проєкт, до якого більшість організацій приходить протягом року. Важливо, щоб кожен прямий канал мав заявлену причину і власника.
Потім перевірте дві схеми, а не одну. Для звичайного шляху запустіть traceroute з кожного майданчика до кожного сервісного префікса й переконайтеся, що хопи збігаються зі схемою. Для шляху відмови вимкніть один тунель і повторіть, бо маршрут, який працює лише поки все піднято, не спроєктований, а лише налаштований.
Тримайте обидві схеми разом із матрицею доступу і повертайтеся до них, коли додається майданчик; вартість, якою ви керуєте, — це вартість наступної зміни, а не елегантність поточної картинки.