SoftEther VPN Azure: шлях праз рэлей, а не адкрыты порт

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

Што змяняецца на шляху

Пры звычайным слухачы кліент адкрывае TCP-злучэнне да публічнага адраса, які ваш маршрутызатар перадае серверу. Пры рэлеі сервер падтрымлівае зыходнае злучэнне да інфраструктуры рэлея, а рэлей прымае кліенцкія злучэнні і перадае іх нагрузку серверу, які чакае. Ніякі ўваходны порт не адкрываецца, статычны адрас не патрабуецца, а маршрутызатар застаецца некранутым. З пункту гледжання файрвола сервер — звычайны зыходны кліент, таму абмежавальныя сеткі яго дазваляюць.

Рэлей прысвойвае гэтаму серверу імя ў сваім дамене, і кліенты наладжваюцца на падключэнне туды.

Гэтае імя належыць сэрвісу рэлея, які не з'яўляецца Microsoft Azure VPN Gateway, хоць абодва называюцца Azure нешта. Стаўленне да іх як да ўзаемазаменных дае канфігурацыю, якая не можа працаваць.

Якія пратаколы праходзяць праз рэлей

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

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

Што рэлей не робіць за вас

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

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

Праверка сертыфікатаў і аўтэнтыфікацыя карыстальнікаў застаюцца абавязкам сервера, і рэлей ніколі не замяняе ні адно з іх.

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

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

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

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