SoftEther VPN Azure: шлях через ретранслятор, а не відкритий порт

Ваш сервер стоїть за маршрутизатором, який ви не можете налаштувати, тому очевидний план переадресації порту недоступний. VPN Azure існує саме для такої ситуації й вирішує її, розвертаючи напрямок першого з'єднання: сервер підключається назовні до ретранслятора, а клієнти досягають ретранслятора замість сервера. Розуміння цього розвороту пояснює і те, що виправляє сервіс, і кожне обмеження, з яким ви зіткнетеся пізніше.

Що змінюється на шляху

Зі звичайним слухачем клієнт відкриває TCP-з'єднання до публічної адреси, яку ваш маршрутизатор пересилає на сервер. З ретранслятором сервер підтримує вихідне з'єднання до інфраструктури ретранслятора, а ретранслятор приймає клієнтські з'єднання й передає їхнє навантаження серверу, що чекає. Вхідний порт не відкривається, статична адреса не потрібна, а маршрутизатор залишається недоторканим. З погляду брандмауера сервер — звичайний вихідний клієнт, тому обмежувальні мережі його пропускають.

Ретранслятор призначає цьому серверу ім'я у своєму домені, і клієнти налаштовуються на підключення туди.

Це ім'я належить службі ретранслятора, яка не є Microsoft Azure VPN Gateway, хоча обидві називаються Azure щось. Ставлення до них як до взаємозамінних дає конфігурацію, яка не може працювати.

Які протоколи проходять через ретранслятор

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

Тому клієнтські профілі вказують на ім'я ретранслятора, а не на адресу сервера, і наявний профіль, створений для прямого підключення, не працюватиме без змін. Перш ніж проєктувати навколо протоколу, який ретранслятор не передає, перегляньте список підтримуваних клієнтів для вашої версії.

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

Ретранслятор — це транспорт. Він не створює користувачів, віртуальні концентратори, політики доступу чи маршрути й нічого не знає про приватні мережі за вашим сервером. Якщо віддалені клієнти мають досягти підмережі LAN, серверу все ще потрібні конфігурація мосту або маршрутизації, зворотний шлях і політика брандмауера, які це забезпечують. Перекривані плани адрес на обох кінцях також невидимі для ретранслятора й залишаються вашим завданням.

Підтримувані параметри безпеки теж обираєте ви. Документація проєкту містить приклади старіших платформ, а копіювання застарілих налаштувань шифрування чи сертифікатів зі старого знімка екрана — добрий спосіб збудувати тунель, який ніхто не зможе перевірити. Використовуйте актуальні настанови для вашої версії.

Перевірка сертифікатів і автентифікація користувачів залишаються обов'язком сервера, і ретранслятор ніколи не замінює ані того, ані того.

Експлуатуйте його як залежність

Доступність тепер включає третю сторону. Коли ретранслятор недоступний, клієнти не можуть підключитися незалежно від того, наскільки здоровий ваш сервер, і збій ззовні виглядає як проблема клієнта. Відстежуйте шлях через ретранслятор окремо від стану сервера й тримайте задокументований запасний варіант, наприклад прямий слухач на іншій адресі, на той день, коли це буде важливо.

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

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