SoftEther за NAT: прямое прохождение или ретранслятор VPN Azure?

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

Три механизма, три разных обещания

Динамический DNS — это именование. Он удерживает имя хоста направленным на меняющийся адрес, чтобы люди перестали гоняться за номером, и больше ничего не делает. Собственное прохождение NAT — это координация: две конечные точки SoftEther обмениваются информацией и пытаются открыть пригодный путь UDP через устройства трансляции между ними. VPN Azure — это ретранслятор: сервер сам подключается к службе, а клиенты приходят через имя хоста в инфраструктуре ретранслятора.

Эти три дополняют друг друга, а не являются версиями одной функции. Развёртывание может использовать именование, тогда как его соединение на самом деле зависит от прохождения или от ретранслятора.

Решайте исходя из клиента и сети

Выбор начинается с клиента, потому что прохождение существует только в собственном механизме подключения SoftEther. OpenVPN, L2TP/IPsec и прослушиватели SSTP на том же сервере его не наследуют, хотя делят один хост. Посмотрите, что будет запускать пользователь, а затем что разрешает сеть. Корпоративная сеть, разрешающая только TCP 443, толкает вас к ретранслятору на этом порту, тогда как сеть, пропускающая порты UDP, нужные для прохождения, может попробовать прямой путь; подтвердите и то и другое по фактической политике исходящего трафика.

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

Подтвердите, какой транспорт выбрал сеанс

Состояние подключения — единственный честный источник о используемом пути. Прочитайте его на сервере и разрешите имя хоста, которое получил клиент.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

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

Планируйте, от чего зависит выбранный путь

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

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