NAT arxasında SoftEther: birbaşa keçid, yoxsa VPN Azure relay?

SoftEther serveriniz dəyişdirə bilmədiyiniz provayder marşrutlaşdırıcısının arxasındadır, müştərilər isə yenə qoşulur, ona görə hər şeyi relay daşıyır deyə fərz edirsiniz. Bunun doğru olub-olmadığı işi hansı mexanizmin gördüyündən asılıdır: DNS adı, koordinasiyalı UDP yolu və ya relay-ə çıxan tunel. Hər üçü qoşulmuş müştəri yarada bilər və onlar fərqli şəraitdə sıradan çıxır. İstifadəçilərə və ya hub-lara toxunmazdan əvvəl hansı yolu aldığınıza qərar verin.

Üç mexanizm, üç fərqli vəd

Dinamik DNS adlandırmadır. O, host adını dəyişən ünvana yönəldilmiş saxlayır ki, insanlar rəqəmin arxasınca qaçmağı dayandırsın, başqa heç nə etmir. Doğma NAT keçidi koordinasiyadır: iki SoftEther son nöqtəsi məlumat mübadiləsi edir və aralarındakı tərcümə cihazlarından istifadə edilə bilən UDP yolu açmağa çalışır. VPN Azure relay-dir: server xidmətə çıxış edir, müştərilər isə relay infrastrukturundakı host adı vasitəsilə gəlir.

Bu üçü bir funksiyanın versiyaları deyil, bir-birini tamamlayır. Yerləşdirmə adlandırmadan istifadə edə bilər, halbuki onun bağlantısı əslində keçiddən və ya relay-dən asılıdır.

Müştəridən və şəbəkədən qərar verin

Seçim müştəridən başlayır, çünki keçid yalnız doğma SoftEther qoşulma mexanizmində mövcuddur. Eyni serverdəki OpenVPN, L2TP/IPsec və SSTP dinləyiciləri onu miras almır, baxmayaraq ki, bir hostu paylaşırlar. İstifadəçinin nə işlədəcəyinə, sonra şəbəkənin nəyə icazə verdiyinə baxın. Yalnız TCP 443-ə icazə verən korporativ şəbəkə sizi həmin portdakı relay-ə yönəldir, keçidin ehtiyac duyduğu UDP portlarını keçirən şəbəkə isə birbaşa yolu sınaya bilər; hər ikisini faktiki çıxış siyasəti ilə təsdiqləyin.

Əl ilə əlçatan dinləyici, administrator onu dərc edə bildikdə hələ də qanuni dizayndır, lakin bu, öz ünvanlaşdırması və firewall işi olan ayrı bir layihədir.

Sessiyanın hansı nəqliyyatı seçdiyini təsdiqləyin

Bağlantı statusu istifadədəki yol üçün yeganə dürüst mənbədir. Onu serverdə oxuyun və müştəriyə verilən host adını həll edin.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList hansı sessiyaların qoşulduğunu göstərir, onlardan biri üzərində SessionGet isə bağlantı növünü, o cümlədən sessiyanın relay vasitəsilə gəlib-gəlmədiyini bildirir. Relay infrastrukturuna həll olunan qeyd sessiyanın üçüncü tərəfdən keçdiyini deyir, bunu testdə həmin marşrutu bloklayaraq təsdiqləyə bilərsiniz. Doğma müştəridə UDP sürətləndirməsi məlumat yolunu idarəetmə yolundan uzaqlaşdıra bilər, ona görə bir müşahidə bütün sessiyanı təsvir etmir. Ünvan dəyişikliyindən sonra köhnəlmiş dinamik DNS adı və arxa plan marşrutu yoxkən cavab verən relay ayrı-ayrı sınaqdan keçirilməli iki nasazlıq rejimidir. Dizaynın nəzərdə tutduğunu deyil, ölçdüyünüzü qeyd edin.

Seçilmiş yolun nədən asılı olduğunu planlaşdırın

Hər yol bir asılılıq daşıyır. Birbaşa keçid şəbəkə keçidindən və ya yeni tərcümə cihazından sonra dəyişə bilər, relay sessiyası isə xidmət və ya onun əlçatan portu sıradan çıxanda uğursuz olur. Fərqli şəbəkədən yenidən qoşulun və müştərinin yoxladığı server kimliyini təsdiqləyin, əvvəl işləyən yolu həmin testdə saxlayın. Sonra VPN arxasındakı şəxsi resursu sınayın, çünki avtorizasiya, hub üzvlüyü, ünvan təyini və qayıdış marşrutları hər halda sizin məsuliyyətiniz olaraq qalır.

Host adını, protokolu, funksiya parametrlərini və müşahidə olunan nəqliyyatı yazın. Məhz bu dörd hissəli qeyd növbəti şəxsin işlək bağlantını təkrar yaratmasına imkan verir.