SoftEther VPN Azure: път през релей, а не отворен порт

Вашият сървър стои зад рутер, който не можете да конфигурирате, затова очевидният план за пренасочване на порт не е наличен. VPN Azure съществува точно за тази ситуация и я решава, като обръща посоката на първата връзка: сървърът се свързва навън към релей, а клиентите достигат до релея вместо до сървъра. Разбирането на това обръщане обяснява както какво поправя услугата, така и всяко ограничение, на което ще попаднете по-късно.

Какво се променя по пътя

При конвенционален слушател клиентът отваря TCP връзка към публичен адрес, който вашият рутер препраща към сървъра. При релея сървърът поддържа изходяща връзка към инфраструктурата на релея, а релеят приема клиентски връзки и предава техния товар на чакащия сървър. Не се отваря входящ порт, не се изисква статичен адрес и рутерът остава незасегнат. От гледна точка на защитната стена сървърът е обикновен изходящ клиент и затова ограничителните мрежи го разрешават.

Релеят дава на този сървър име в собствения си домейн и клиентите се конфигурират да се свързват там.

Това име принадлежи на услугата релей, която не е Microsoft Azure VPN Gateway, макар и двете да се наричат Azure нещо. Третирането им като взаимозаменяеми води до конфигурация, която не може да работи.

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

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

Затова клиентските профили сочат към името на релея, а не към адреса на сървъра, и съществуващ профил, създаден за директна връзка, няма да работи без промени. Проверете списъка с поддържани клиенти за версията, която използвате, преди да проектирате около протокол, който релеят не пренася.

Какво релеят не прави вместо вас

Релеят е транспорт. Той не създава потребители, виртуални хъбове, политики за достъп или маршрути и не знае нищо за частните мрежи зад вашия сървър. Ако отдалечени клиенти трябва да достигнат подмрежа на LAN, сървърът все още се нуждае от конфигурацията на мост или маршрутизация, обратния път и политиката на защитната стена, които правят това възможно. Припокриващите се адресни планове в двата края също са невидими за релея и остават ваш проблем за решаване.

Поддържаните настройки за сигурност също са ваши за избор. Документацията на проекта включва примери за по-стари платформи и копирането на остарели настройки за шифроване или сертификати от стар екранен снимок е добър начин да изградите тунел, който никой не може да одитира. Използвайте актуалните указания за версията, която използвате.

Валидирането на сертификати и удостоверяването на потребители остават отговорност на сървъра и релеят никога не замества нито едно от двете.

Експлоатирайте го като зависимост

Наличността вече включва трета страна. Когато релеят е недостъпен, клиентите не могат да се свържат независимо колко здрав е вашият сървър и отвън отказът изглежда като проблем на клиента. Наблюдавайте пътя през релея отделно от здравето на сървъра и поддържайте документиран резервен план, например директен слушател на друг адрес, за деня, в който това ще има значение.

Закъснението следва географията на релея, а не близостта на вашите потребители, което си струва да се измери, преди да обещаете интерактивна производителност през него.

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