Gəzən VPN müştərisi ofis üçün xidmət saxlaya bilərmi?

Gəzən müştəri ofis sistemlərinə yalnız şlüz ona marşrutlaşdırdıqda, host siyasəti buna icazə verdikdə və cihaz kifayət qədər uzun müddət əlçatan qaldıqda xidmət edə bilər.

Ofis noutbukunuz evdən qoşula və yenə də ofisin ehtiyac duyduğu bir şeyi təqdim edə bilər, ancaq yalnız üç ayrı qərar üst-üstə düşdükdə. Tunel nəqliyyatdır, daxili ünvan təyinatdır, siyasət isə kimin qapını döyə biləcəyini müəyyən edir. Bunlardan hər hansı birini tam cavab kimi qəbul etmək, host pinqlərə cavab verir, amma tətbiq heç vaxt qoşulmur şəklində tanış şikayəti doğurur. Rollar eyni deyil və fərq məhz dizayn işinin yerləşdiyi yerdir.

Qoşulma istiqaməti xidmət istiqaməti haqqında heç nə demir

Müştəri tunel başlatdıqda, o, mövcud olduqdan sonra hər iki istiqamətin istifadə edə biləcəyi yol açır. Yeni bağlantının mərkəzdən həmin müştəriyə doğru girə bilib-bilməməsi şlüz siyasəti məsələsidir, kimin qoşulduğunun xassəsi deyil. Məsələn, marşrutlaşdırılmış OpenVPN mərkəzində serverə müştərinin daxili ünvanına marşrut və peer əlaqəsinə icazə verən yönləndirmə lazımdır.

Gəzən noutbuklardakı agenti yoxlayan inventar sistemi və ya evdəki iş stansiyasından test API-sinə ehtiyacı olan tərtibatçı təsəvvür edin. Hər ikisi ofis tərəfinin söhbətə başlamasını istəyir ki, bu da adi müştəri-server modelinin əksidir.

Hostinqdə olan uzaq giriş məhsulları burada fərqlənir və bu fərq xəta deyil. Bəzi idarə olunan VPN-lər qoşulmuş müştərilərə qarşı sorğusuz bağlantıları qəsdən bloklayır, çünki onların modeli resursa-müştəri deyil, müştəridən-resursa modelidir. Həmkarınıza noutbukunun server rolunu oynaya biləcəyini vəd etməzdən əvvəl məhsulun sənədləşdirilmiş arxitekturasını oxuyun.

Port açmazdan əvvəl cavab yolunu izləyin

Yolun üç hissəsi var: şlüzdə müştərinin daxili ünvanına yönələn marşrut, konkret çağırana icazə verən siyasət və hədəfdə dinləyən xidmət. Hər hissə fərqli şəkildə sıradan çıxır, buna görə də «VPN işləyir» ifadəsi demək olar ki, heç nə demir.

Yaxşı xəbər odur ki, daxili yol müştərinin ev marşrutlaşdırıcısında port yönləndirməsi tələb etmir. Xidmətin ev WAN ünvanında deyil, tunel ünvanında yerləşdirilməsinin mənası budur, çünki orada məruz qalma və NAT qaydaları tamamilə fərqli olardı. Ev marşrutlaşdırıcısı həmçinin ofisdən gələn bağlantını geri qatmaqdan imtina edə bilər, beləliklə WAN yolu VPN-inizlə əlaqəsi olmayan səbəblərdən sıradan çıxır. Trafiki tunelin içində saxlamaq hər iki problemi birdən aradan qaldırır.

Hədəf tərəfini də yoxlayın. Yalnız 127.0.0.1 ünvanına bağlanmış xidmət tunel interfeysinə gələn bağlantını qəbul edə bilməz, şlüz marşrutları nə qədər düzgün olsa da. Portu yalnız yerli alt şəbəkədən buraxan host firewall qaydası da ofis trafikini atacaq və həmin qayda yuxarıdakı VPN siyasətindən asılı deyil.

Adlar və ünvanlar dizayn qərarlarıdır

Tunelin içindəki ünvan avtomatik olaraq ad deyil. Nəzarət etdiyiniz şəxsi DNS qeydi, kəşf protokolunun tuneldən keçəcəyinə ümid bəsləməkdən daha aydındır, çünki link-local multicast ad həlli yerli seqmentdə qalır və alt şəbəkələr arası DNS-ə çevrilmir.

Ünvan sabitliyi də eyni dərəcədə vacibdir. VPN müştəriləri qısa icarə müddətli hovuzdan ünvan götürürsə, noutbukun daxili ünvanı sessiyalar arasında dəyişir və onun üzərində qurulmuş hər əlfəcin, firewall əhatəsi və monitorinq yoxlaması səssizcə pozulur. Rezervasiya və ya sənədləşdirilmiş dinamik yeniləmə yolu istifadə edin.

Adı VPN kimliyinin sahibi ilə razılaşdırın ki, qeyd, ünvan təyinatı və giriş siyasəti üç ayrı biletdə deyil, birlikdə dəyişsin.

Üzvlüyü deyil, xidməti sınayın

Hədəfdən nəyin və hansı ünvanda dinlədiyini təsdiqləyin, sonra şlüzün qayıdış yolu barədə görüşünü təsdiqləyin:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

İndi ofis tərəfindən əks-səda deyil, real sorğu ilə sınaqdan keçirin. Xidmətə qarşı uğurlu curl marşrutu, siyasəti və dinləyicini bir anda sübut edir, pinq uğuru isə yalnız ICMP-yə icazə verildiyini sübut edir. Sorğu uğursuz olarsa, firewall-ı genişləndirib ümid etmək əvəzinə üç hissədən geriyə doğru işləyin.

Əlçatanlıq eyni söhbətin içindədir. Noutbuk yatır, şəbəkələr arasında gəzir və günün sonunda ayrılır. İstənilən saatda cavab verməli xidmət həmişə işləyən hostda olmalıdır, ən yaxşı səylə işləyən xidmət isə bu məhdudiyyət yazılmaqla müştəridə qala bilər.

Resursu qəsdən dərc edin — ad, icazə verilmiş çağıranlar siyahısı və sahib ilə — və uzaq cihaz təsadüfi server deyil, dəstəklənən xidmətə çevrilir.

Əlaqəli məqalələr