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

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

Шта се мења на путањи

Са конвенционалним слушаоцем, клијент отвара TCP везу ка јавној адреси коју ваш рутер прослеђује серверу. Са релејем, сервер одржава излазну везу ка инфраструктури релеја, а релеј прихвата клијентске везе и предаје њихов терет серверу који чека. Ниједан улазни порт се не отвара, статична адреса није потребна и рутер остаје нетакнут. Из угла заштитног зида сервер је обичан излазни клијент, због чега га ограничене мреже дозвољавају.

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

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

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

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

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

Шта релеј не ради за вас

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

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

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

Управљајте њиме као зависношћу

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

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

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