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

Запішыце імя хоста, пратакол, налады функцыі і назіраны транспарт. Менавіта гэты чатырохчасткавы запіс дазваляе наступнаму чалавеку ўзнавіць працоўнае злучэнне.