SoftEther VPN Azure: патека преку реле, а не отворен порт

Вашиот сервер стои зад рутер што не можете да го конфигурирате, затоа очигледниот план за проследување порта не е достапен. VPN Azure постои токму за таа состојба и ја решава со превртување на насоката на првата врска: серверот се поврзува нанадвор кон реле, а клиентите стигнуваат до релето наместо до серверот. Разбирањето на тоа превртување објаснува и што поправа услугата и секое ограничување на кое ќе наидете подоцна.

Што се менува на патеката

Со конвенционален слушател, клиентот отвора TCP врска кон јавна адреса што вашиот рутер ја проследува до серверот. Со релето, серверот одржува излезна врска кон инфраструктурата на релето, а релето прифаќа клиентски врски и го предава нивниот товар на серверот што чека. Не се отвора влезна порта, не се бара статична адреса и рутерот останува недопрен. Од гледна точка на огнениот ѕид, серверот е обичен излезен клиент и затоа ограничувачките мрежи го дозволуваат.

Релето му доделува име на тој сервер на својот домен и клиентите се конфигурираат да се поврзуваат таму.

Тоа име и припаѓа на услугата реле, која не е Microsoft Azure VPN Gateway иако двете се нарекуваат Azure нешто. Третирањето како заменливи дава конфигурација што не може да работи.

Кои протоколи преживуваат преку релето

Релето го пренесува протоколот SoftEther, а проектот документира SSTP како клиентска опција, што е корисно зашто Windows доаѓа со SSTP клиент. Сепак, не станува општ носач за секој слушател на домаќинот: слушателот OpenVPN, одговорникот IPsec и услугата L2TP секој бара своја достапна крајна точка и ниту еден од нив не се пренесува преку релето само затоа што серверот SoftEther е поврзан.

Затоа клиентските профили покажуваат кон името на релето наместо кон адресата на серверот, а постоечки профил изграден за директна врска нема да работи без измени. Пред да проектирате околу протокол што релето не го пренесува, проверете го списокот со поддржани клиенти за верзијата што ја извршувате.

Што релето не прави за вас

Релето е транспорт. Не создава корисници, виртуелни јазли, политики за пристап или рути и не знае ништо за приватните мрежи зад вашиот сервер. Ако оддалечените клиенти мора да стигнат до подмрежа на LAN, серверот сѐ уште ја бара конфигурацијата за мост или рутирање, повратната патека и политиката на огнениот ѕид што тоа го овозможуваат. Преклопувачките адресни планови на двата краја исто така се невидливи за релето и остануваат ваш проблем за решавање.

Поддржаните безбедносни поставки исто така се ваши за избор. Документацијата на проектот вклучува примери од постари платформи, а копирањето застарени поставки за шифрирање или сертификати од стар екрански снимак е добар начин да изградите тунел што никој не може да го ревидира. Користете актуелни упатства за верзијата што ја извршувате.

Валидацијата на сертификати и автентикацијата на корисници остануваат одговорност на серверот и релето никогаш не заменува ниту едно од двете.

Управувајте со него како зависност

Достапноста сега вклучува трета страна. Кога релето е недостапно, клиентите не можат да се поврзат без оглед колку е здрав вашиот сервер, а дефектот однадвор изгледа како клиентски проблем. Следете ја патеката преку релето одделно од здравјето на серверот и држете документиран резервен план, како директен слушател на друга адреса, за денот кога тоа ќе биде важно.

Задоцнувањето ја следи географијата на релето наместо близината на вашите корисници, што вреди да се измери пред да ветите интерактивни перформанси преку него.

Проверете го идентитетот на серверот, а потоа вистинска апликациска патека, не само успешен банер за поврзување, и проверете дали ресурсот што ви треба е достапен преку адресното семејство што релето го пренесува. Запишете го името на релето, користениот протокол и резервниот план, зашто овие три факти одговараат на повеќето идни прашања за оваа врска.