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

Динамічний DNS, проходження 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, бо авторизація, членство в концентраторі, призначення адрес і зворотні маршрути в будь-якому разі залишаються вашою відповідальністю.

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

Схожі статті