SoftEther VPN Azure: путь через ретранслятор, а не открытый порт

Ваш сервер стоит за маршрутизатором, который вы не можете настроить, поэтому очевидный план проброса порта недоступен. VPN Azure существует именно для такой ситуации и решает её, разворачивая направление первого соединения: сервер подключается наружу к ретранслятору, а клиенты достигают ретранслятора вместо сервера. Понимание этого разворота объясняет и то, что исправляет сервис, и каждое ограничение, с которым вы столкнётесь позже.

Что меняется на пути

При обычном слушателе клиент открывает TCP-соединение к публичному адресу, который ваш маршрутизатор переправляет на сервер. При ретрансляторе сервер поддерживает исходящее соединение к инфраструктуре ретранслятора, а ретранслятор принимает клиентские соединения и передаёт их нагрузку ожидающему серверу. Входящий порт не открывается, статический адрес не требуется, а маршрутизатор остаётся нетронутым. С точки зрения брандмауэра сервер — обычный исходящий клиент, поэтому ограничительные сети его пропускают.

Ретранслятор назначает этому серверу имя в своём домене, и клиенты настраиваются на подключение туда.

Это имя принадлежит службе ретранслятора, которая не является Microsoft Azure VPN Gateway, хотя обе называются Azure что-то. Отношение к ним как к взаимозаменяемым даёт конфигурацию, которая не может работать.

Какие протоколы проходят через ретранслятор

Ретранслятор передаёт протокол SoftEther, и проект документирует SSTP как клиентский вариант, что полезно, поскольку Windows поставляется с клиентом SSTP. Однако он не становится универсальным носителем для каждого слушателя на хосте: слушателю OpenVPN, ответчику IPsec и службе L2TP нужна своя доступная конечная точка, и ни один из них не передаётся через ретранслятор только потому, что сервер SoftEther подключён.

Поэтому клиентские профили указывают на имя ретранслятора, а не на адрес сервера, и существующий профиль, созданный для прямого подключения, не будет работать без изменений. Прежде чем проектировать вокруг протокола, который ретранслятор не передаёт, проверьте список поддерживаемых клиентов для вашей версии.

Чего ретранслятор для вас не делает

Ретранслятор — это транспорт. Он не создаёт пользователей, виртуальные концентраторы, политики доступа или маршруты и ничего не знает о частных сетях за вашим сервером. Если удалённым клиентам нужно достичь подсети LAN, серверу по-прежнему нужны конфигурация моста или маршрутизации, обратный путь и политика брандмауэра, которые это обеспечивают. Перекрывающиеся планы адресации на обоих концах тоже невидимы для ретранслятора и остаются вашей задачей.

Поддерживаемые параметры безопасности тоже выбираете вы. Документация проекта содержит примеры старых платформ, а копирование устаревших настроек шифрования или сертификатов со старого снимка экрана — хороший способ построить туннель, который никто не сможет проверить. Используйте актуальные рекомендации для вашей версии.

Проверка сертификатов и аутентификация пользователей остаются обязанностью сервера, и ретранслятор никогда не заменяет ни то, ни другое.

Эксплуатируйте его как зависимость

Доступность теперь включает третью сторону. Когда ретранслятор недоступен, клиенты не могут подключиться независимо от того, насколько здоров ваш сервер, и сбой снаружи выглядит как проблема клиента. Следите за путём через ретранслятор отдельно от состояния сервера и держите задокументированный запасной вариант, например прямой слушатель на другом адресе, на тот день, когда это будет важно.

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

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