Bir OpenVPN portu, üç xidmət: daxili portlar niyə vacibdir

Bir SSH sessiyası, bir veb tətbiqi və bir ad sorğusu portlar uğrunda yarışmadan tək bir VPN bağlantısını paylaşa bilər. Müştəri şlüzə tək şifrələnmiş axın qurur və hər tətbiq söhbəti onun içində hərəkət edir. Xaricdə yalnız tunelin öz nəqli və portu görünür. İçəridə isə hər xidmət öz portunu saxlayır və hələ də öz icazəsinə ehtiyac duyur.

Xarici axın nəyi daşıyır və nəyi gizlədir

Müştəri hər paketi maşından çıxmazdan əvvəl tunelin nəqli içində bükür. Bu xarici axının bir təyinat portu var və o, VPN quraşdırılarkən təyin edilir. Bükükün içində hər orijinal paket hədəflədiyi xidmətin ünvanını və portunu saxlayır. Şlüz büküyü soyur və daxili başlığa görə marşrutlaşdırır, beləliklə təyinat şəbəkədən gələn adi bir müştəri görür.

Buna görə WAN interfeysindəki tutma üç yox, bir söhbət göstərir. Daxili portlar yalnız dekapsulyasiyadan sonra görünür. Elə buna görə tək bir firewall deşiyi SSH, HTTPS və DNS-i eyni vaxtda daşıya bilər.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP sənədləşməsi IP paketlərinin nüvə ilə istifadəçi məkanındakı proses arasında ötürüldüyü keçidi əhatə edir. Bu keçid daxili başlığı şlüzün marşrutlaşdırma və firewall koduna görə görünən edir. O, həmçinin xarici portun hansı xidmətlərə icazə verildiyi barədə heç nə demədiyini izah edir.

NAT yönləndirməsi tətbiqlərə deyil, dinləyiciyə aiddir

IPv4 NAT arxasında özünün yerləşdirdiyi şlüz bir gələn çevirmə tələb edir: ictimai ünvan və port VPN dinləyicisinə xəritələnir. Yalnız tunel istifadəçiləri onlara çatdığı üçün SSH, HTTPS və ya DNS üçün heç bir qayda tələb olunmur. Həmin portları açıqlamaq tunelin artıq qoruduğu xidmətləri ifşa edərdi. Yönləndirmə qaydası dinləyicinin əldə edilə bilməsini təsvir edir, içəridəki hər hansı şey üçün icazəni yox.

Əksi də doğrudur. Tunel portunu açmaq başqa heç nəyi ifşa etmir, ona görə yalnız tunel vasitəsilə əldə edilə bilən xidmətin ictimai səthi bağlı qalır. Bu ayrım adətən xidməti elə əvvəldən şəxsi saxlamağın səbəbidir.

Girişə faktiki olaraq daxili siyasətdə qərar verilir

Şifrələmə yolu qoruyur; təyinatı avtorizasiya etmir. Müştəri marşrutları hansı prefikslərin tunelə girdiyini seçir, şlüzün yönləndirmə siyasəti paketlərin onu tərk edib-etməyəcəyini qərar verir, təyinatın firewall-u və girişi isə xidmətin cavab verib-verməyəcəyini həll edir. DNS ən aydın haldır: sorğuları daşımaq həlledicinin onları sizin müştəri hovuzunuzdan qəbul etməsinə səbəb olmur. Hər qat müstəqil şəkildə yox deyə bilər.

Hər xidməti tunel vasitəsilə ayrıca sına. Uğurlu axtarış veb portu barədə heç nə demir, uğurlu veb sorğusu isə SSH barədə heç nə demir.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Tunel işləyəndə və hər şey uğursuz olanda əvvəlcə müştərinin marşrut cədvəlini oxu. Bir xidmət uğursuz olub digərləri işləyəndə nasazlıq həmin təyinatdadır. Bu iki müşahidə fərqli sahiblərə işarə edir və onları qarışdırmaq vaxt itkisidir.

WireGuard eyni xətti çəkir

WireGuard xarici dinləyicisini ListenPort ilə adlandırır, daxili tətbiq isə ehtiyac duyduğu istənilən xidmət portunu istifadə edir. AllowedIPs yönləndirilmiş prefikslər çoxluğudur, icazə verilmiş xidmət portlarının siyahısı deyil. Onu port icazə siyahısı kimi oxumaq tunelin etdiyi ilə uyğun gəlməyən qaydalar yaradır. Adlandırma fərqlidir; qatlaşma deyil.

Xidmət son nöqtənin özündə işləyəndə yerli giriş siyasətində, həmin nöqtənin arxasında yerləşəndə isə yönləndirmə siyasətində icazə verin. Bu fərq paketi hansı qayda dəstinin gördüyünü müəyyən edir.

Ümumi forma çoxsaylı daxili söhbətləri olan bir xarici nəqlidir. Bir neçə xarici mübadilə və ya fərqli IP protokolu tələb edən məhsullar, tək ictimai port nümunəsinin bu dizaynı təsvir etdiyini, hər VPN-i yox, xatırladır.