Серверіңіз конфигурациялай алмайтын маршрутизатордың артында, сондықтан портты бағыттау жоспары қолжетімсіз. VPN Azure дәл осы жағдай үшін бар және оны бірінші қосылымның бағытын өзгерту арқылы шешеді: сервер сыртқа релеге қосылады, ал клиенттер сервердің орнына релеге жетеді. Бұл өзгерісті түсіну қызметтің нені түзететінін және кейін кездесетін әр шектеуді түсіндіреді.

Жолда не өзгереді

Әдеттегі тыңдаушыда клиент маршрутизаторыңыз серверге жіберетін жария мекенжайға TCP қосылымын ашады. Релемен сервер реле инфрақұрылымына шығыс қосылымын ұстайды, ал реле клиент қосылымдарын қабылдап, олардың жүктемесін күтіп тұрған серверге жібереді. Кіріс порты ашылмайды, статикалық мекенжай қажет емес, ал маршрутизатор тиіспеген күйде қалады. Өрт қабырғасы тұрғысынан сервер қарапайым шығыс клиенті, сондықтан шектеулі желілер оған рұқсат береді.

Реле сол серверге өз доменінде атау береді, ал клиенттер сол жерге қосылуға конфигурацияланады.

Бұл атау реле қызметіне тиесілі, ол Microsoft Azure VPN Gateway емес, екеуі де Azure әлдене деп аталса да. Оларды ауыспалы деп қарау жұмыс істей алмайтын конфигурация тудырады.

Қандай протоколдар реледен өтеді

Реле SoftEther протоколын тасымалдайды, ал жоба SSTP параметрін клиент опциясы ретінде құжаттайды, бұл пайдалы, себебі Windows-та SSTP клиенті бар. Алайда ол хосттағы әр тыңдаушы үшін жалпы тасымалдаушыға айналмайды: OpenVPN тыңдаушысы, IPsec жауап берушісі және L2TP қызметі әрқайсысына өз қолжетімді соңғы нүктесі қажет, және ешқайсысы SoftEther сервері қосылғандықтан ғана реледен өтпейді.

Сондықтан клиент профильдері сервер мекенжайының орнына реле атауын көрсетеді, ал тікелей қосылым үшін құрылған бар профиль өзгеріссіз жұмыс істемейді. Реле тасымалдамайтын протокол айналасында жобаламас бұрын пайдаланатын нұсқаңыз үшін қолдау көрсетілетін клиенттер тізімін қараңыз.

Реле сіз үшін не істемейді

Реле — тасымалдаушы. Ол пайдаланушылар, виртуалды хабтар, қатынау саясаттары немесе маршруттар жасамайды және серверіңіздің артындағы жеке желілер туралы ештеңе білмейді. Егер қашықтағы клиенттер LAN ішкі желісіне жетуі керек болса, серверге әлі де көпір немесе маршруттау конфигурациясы, қайту жолы және мұны мүмкін ететін өрт қабырғасы саясаты қажет. Екі ұштағы қабаттасатын мекенжай жоспарлары да реле үшін көрінбейді және сіздің шешетін мәселеңіз болып қалады.

Қолдау көрсетілетін қауіпсіздік параметрлерін де сіз таңдайсыз. Жоба құжаттамасында ескі платформалардың мысалдары бар, ал ескі скриншоттан ескірген шифрлау немесе сертификат параметрлерін көшіру ешкім тексеріп-бақылай алмайтын туннель салудың жақсы жолы. Пайдаланатын нұсқаңыз үшін ағымдағы нұсқаулықты қолданыңыз.

Сертификаттарды валидациялау және пайдаланушыларды аутентификациялау сервердің жауапкершілігінде қалады, ал реле олардың ешқайсысын ешқашан алмастырмайды.

Оны тәуелділік ретінде пайдаланыңыз

Қолжетімділік енді үшінші тарапты қамтиды. Реле қолжетімсіз болғанда, серверіңіз қаншалықты сау болса да клиенттер қосыла алмайды, ал ақау сырттан клиент мәселесі сияқты көрінеді. Реле жолын сервердің өз саулығынан бөлек бақылаңыз және бұл маңызды болатын күн үшін басқа мекенжайдағы тікелей тыңдаушы сияқты құжатталған резервтік жоспар ұстаңыз.

Кідіріс пайдаланушыларыңыздың жақындығына емес, реленің географиясына сүйенеді, оны осы арқылы интерактивті өнімділікке уәде бермес бұрын өлшеу керек.

Сервердің жеке басын, содан кейін нақты қолданба жолын тексеріңіз, тек сәтті қосылым баннерін ғана емес, және қажетті ресурс реле тасымалдайтын мекенжайлар отбасы арқылы қолжетімді ме, соны тексеріңіз. Реле атауын, пайдаланылған протоколды және резервтік жоспарды жазып алыңыз, өйткені осы үш дерек осы байланыс туралы болашақ сұрақтардың көбіне жауап береді.

Қатысты мақалалар