Одній ВМ Azure потрібен тунель: гостьовий клієнт чи VPN-шлюз?
Три умови вирішують, чи має одна ВМ Azure запускати власний клієнт VPN, чи підключення радше належить до мережевого рівня.
Одне робоче навантаження в одній ВМ Azure має потрапити до приватної мережі через тунель. Питання, що визначає архітектуру, не в тому, який продукт VPN кращий, а в тому, чи знадобиться колись цей шлях іншій машині. Дайте відповідь на це першим, і решта архітектури зазвичай обирається сама. Помилитеся — успадкуєте ВМ, яка тихо стала маршрутизатором, якого ніхто не задокументував.
Дві задачі, які виглядають однаково
ВМ може бути кінцевою точкою або транзитним пунктом, і різниця не в програмному забезпеченні, яке ви встановлюєте, а в тому, хто споживає тунель. Як кінцева точка гість запускає клієнт для власних процесів. Як транзитний пункт він пересилає пакети інших навантажень, стаючи частиною топології вашої мережі.
| Задача | Що робить ВМ | Хто відповідає за маршрутизацію |
|---|---|---|
| Кінцева точка навантаження | Запускає підтримуваний клієнт для власних процесів | Маршрути гостя обирають схвалені призначення |
| Транзитний пристрій | Пересилає інші навантаження в підключення до майданчика | Таблиці маршрутів підмережі, пересилання NIC, політика гостя та зворотні шляхи |
Більшість запитів щодо однієї ВМ — це перша задача в одежі другої. Хтось каже «ВМ — це наш VPN», маючи на увазі, що застосунку на ній треба дістатися бази даних на іншому боці.
Умова перша: чи потрібен далекий бік ще чомусь?
Якщо відповідь «ні», встановіть клієнт у гості й припиніть проєктувати. Ніщо в цьому виборі не вимагає керованого шлюзу і ніщо не робить ВМ шлюзом для її сусідів. Ви додаєте маршрут усередині однієї операційної системи.
Якщо відповідь «так» або «ймовірно так протягом року», розглядайте це як мережевий проєкт уже зараз. Інші ВМ потрапляють до транзитної ВМ лише тоді, коли таблиця маршрутів підмережі надсилає їх туди, а NIC приймає пересланий трафік, тож робота — це таблиці маршрутів і дозволи на пересилання, а не чергове встановлення клієнта.
Умова друга: чи вдасться зберегти шлях адміністрування?
Клієнт VPN, який встановлює широкий маршрут, може перехопити шлях, яким ви адмініструєте ВМ. Якщо список призначень тунелю перетинається з мережею керування, ваша сесія SSH або RDP обривається в момент підключення клієнта, і виправлення доведеться вносити через послідовну консоль або перезбирання.
Перевіряйте до і після. У Linux ip route get <management-ip> показує, який інтерфейс і джерело ядро використало б зараз; порівняйте це з відповіддю, коли тунель піднятий. Розділений тунель із явним списком призначень захистити простіше, ніж маршрут за замовчуванням, і зазвичай саме це навантаженню й потрібно.
Умова третя: хто ставить латки опівночі?
Гостьовий клієнт — це ваша операційна система, ваша версія клієнта і ваші сертифікати. Це нормально, коли ви вже експлуатуєте ВМ та її цикл оновлень. Це погана угода, коли ВМ існує лише заради тунелю. Порахуйте години на оновлення, перш ніж називати гостьовий клієнт дешевшим. Оновлення клієнта з перезавантаженням — це простій, який ви самі запланували для машини, що існує заради підтримання тунелю.
Керований шлюз переносить це обслуговування на платформу. Ідентичність, авторизація та мережеві шляхи за ним залишаються вашими, але ви не перезавантажуєте машину заради оновлення клієнта.
Чого керований шлюз не робить
Azure VPN Gateway — це служба зв'язності VNet із власними схемами «майданчик-майданчик» і «точка-майданчик». Це не правило, що забороняє VPN-ПЗ у гості, і не пряма заміна клієнту, потрібному одному застосунку.
Він дає підключення на мережевому рівні, доступне багатьом навантаженням через маршрутизацію. Він не дає тунель, яким користується лише один процес на одній ВМ і який обмежений ідентичністю цього процесу. Ця обмеженість не вада, за яку треба вибачатися; саме в ній сенс схеми з гостьовим клієнтом. Один застосунок, один маршрут, один набір облікових даних, жодного впливу на інші ВМ у підмережі.
Тож порівняння не «кероване проти програмного». Це зв'язність у масштабі мережі проти зв'язності в масштабі процесу, і друга легітимна, коли потрібна лише одному процесу.
Плануйте шлях зростання заздалегідь
Якщо вимога виростає з однієї ВМ до підмережі, перебудуйте проєкт, а не розширюйте дозволені префікси клієнта. Повторне використання зручної сесії в ролі незадокументованого маршрутизатора прив'язує кожного споживача до строку життя цієї ВМ, її облікових даних і вікна оновлень.
Правильна відправна точка, коли підключення належить до масштабу мережі, а не навантаження, — огляд Azure VPN Gateway.
Перш ніж обирати, напишіть три рядки: чому потрібен далекий бік, хто адмініструє ВМ і хто ставить оновлення на тунель. Якщо всі три відповіді вказують на одне навантаження, гостьовий клієнт — чесний проєкт. Якщо хоч одна вказує на підмережу, проєктуйте мережевий рівень зараз.