Одной ВМ 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.
Прежде чем выбирать, напишите три строки: чему нужна дальняя сторона, кто администрирует ВМ и кто ставит обновления на туннель. Если все три ответа указывают на одну нагрузку, гостевой клиент — честный проект. Если хоть один указывает на подсеть, проектируйте сетевой уровень сейчас.