Port yönləndirməsi və VPN girişi: paket əslində hara gedir

İki dizayn, bir HTTPS tətbiqi və paket hər birində fərqli marşrut izləyir. Port yönləndirməsi paketin çatdırıldığı yeri dəyişir və qalan hissəsini toxunmadan qoyur. VPN isə həmin paketi əvvəlcə başqa bir paketin içində daşıyır, buna görə tətbiqin dinləyicisi fərqli mənbə və daha kiçik maksimum yük görür. İnsanların mübahisə etdiyi şifrələmə hər iki halda mövcuddur, çünki tətbiq yenə də HTTPS-dir; fərqli olan, kimin bağlantı aça bilməsi və aradakı şəbəkənin nəyi müşahidə edə bilməsidir. Bu fərq praktik sualların çoxunu həll edir.

DNAT qaydası təyinatı yenidən yazır və orada dayanır

Linux şlüzündə xidmətin yayımlanması nat cədvəlinin PREROUTING zəncirində bir qayda, ya da nftables-də ekvivalenti deməkdir. Qayda açıq ünvanı və portu uyğunlaşdırır, sonra təyinatı tətbiqin özəl ünvanına yenidən yazır. Mənbə ünvanı, mənbə portu və yük toxunulmaz qalır, conntrack isə uyğunluğu qeyd edir ki, cavablar çıxarkən geri yazılsın. Davranış RFC 3022-də təsvir olunan ənənəvi ünvan çevirmə modelidir.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Tətbiqin dinləyicisi bağlantının çevirmə yolu ilə gəldiyini heç vaxt öyrənmir. O, müştərinin həqiqi mənbə ünvanını görür, bu da giriş jurnalları və sürət məhdudiyyətləri üçün faydalıdır, və özəl ünvana cavab verir, çünki conntrack uyğunluğu tərsinə çevirir. Bu yolda heç nə şifrəni açmır və ya yenidən şifrələmir: TLS hələ də müştəri ilə tətbiqin öz sertifikatı arasında işləyir.

Qayda həm də sonra rastlaşacağınız nasazlıq rejimlərini müəyyən edir. Əgər şlüz yönləndirirsə, lakin tətbiqin hostunun müştəriyə qayıtma marşrutu yoxdursa, cavablar səhv mənbə ilə çıxır və əl sıxışması dayanır. Əgər ikinci qayda əvvəl uyğunlaşarsa, nəticəni sıra həll edir və iptables -t nat -L -n -v paketi hansı qaydanın götürdüyünü sübut edən sayğacları göstərir.

Tunel paketi dinləyici görməzdən əvvəl sarır

VPN tətbiqi ümumiyyətlə yayımlamır. Müştəri şlüzün açıq ünvanına ünvanlanmış xarici paket qurur, daxili paketi onun içində şifrələyir, şlüz isə şifrəni açır və daxili paketi özəl təyinatına yönləndirir. WireGuard-da xarici nəqliyyat UDP-dir, adətən yüksək portdadır; OpenVPN TCP 443 üzərində olduqda isə xarici paket yolu izləyən hər şey üçün TLS kimi görünür.

Tunelin içində daxili paket özəl ünvanları saxlayır: müştərinin tunel ünvanı, deyək ki 10.8.0.6, və tətbiq 10.20.30.40 ünvanında. Beləliklə dinləyici tunel hovuzundan bir mənbə görür və hər müştəri həmin şlüzü növbəti sıçrayış kimi paylaşır. VPN arxasındakı giriş jurnalları çox vaxt istifadəçi yerinə məhz bu səbəbdən şlüzü göstərir, məgər şlüz ilkin mənbəni qoruyursa.

Qatlama başlıq sahəsinə başa gəlir və bu, ölçə biləcəyiniz nəticəsi olan yeganə mexanizm səviyyəli fərqdir. Xarici IP başlığı üstəgəl UDP üstəgəl WireGuard-ın öz başlığı marşrutun MTU-sundan yeyir, buna görə böyük paketlər parçalanmalı və ya daxili TCP yığını MSS-ni məhdudlaşdırmalıdır. Yönləndirilmiş yolda işləyən ötürmə, aralıq qurğu daha kiçik MTU-nu bildirəcək ICMP-ni atdıqda tunel üzərində dayana bilər.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Məruz qalma girişdə həll olunur, şifrdə deyil

Hər iki dizayn eyni TLS dinləyicisində bitir, buna görə hər ikisi eyni sertifikatı, eyni protokol versiyalarını və eyni tətbiq girişini miras alır. Dəyişən, kimin əl sıxışmasına başlamağa icazəli olmasıdır. Açıq yönləndirmədə 203.0.113.10:443 ünvanına çata bilən istənilən host TCP əl sıxışması və TLS ClientHello alır, tətbiqin avtorizasiyasına heç baxılmadan. Yalnız tunel girişində isə dinləyici yalnız şlüzün tunelə yönləndirdiyi ünvanlardan əlçatandır və yad adamın SYN-i şlüz siyasətində ölür.

Bu fərq əlçatanlıqla bağlıdır, məxfiliklə deyil. Yönləndirilmiş HTTPS xidməti açıq mətn deyil və VPN tətbiq autentifikasiyasına ehtiyacı aradan qaldırmır: tunelə qəbul cihazın bu şəbəkəyə paket göndərə bilməsi sualına cavab verir, fayl tətbiqi isə istifadəçinin sənədi oxuya bilməsi sualına. İkisini qarışdırmaq komandaların bütün LAN-ı verən VPN və bir ümumi parolla tətbiqlə nəticələnməsinin yoludur.

Dinləyicini və siyasəti ayrı-ayrı yoxlayın, çünki hər biri fərz etdiyinizdən geniş ola bilər:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Əgər ss dinləyicinin 0.0.0.0 ünvanına bağlandığını göstərirsə, tətbiq marşrutlaşdırma və firewall siyasətinin icazə verdiyi hər yerdən əlçatandır və yönləndirmə giriş yollarından yalnız biridir. Özəl ünvana bağlanmaq və ya firewall-da mənbə aralığını məhdudlaşdırmaq VPN seçməkdən ayrı qərardır və məruz qalmanı həqiqətən daraldan qərardır.

Yolu ölçün, etiketi deyil

Kimsə yönləndirmənin daha sürətli olduğunu iddia etdikdə, dürüst müqayisə hər şeyi sabit saxlayır: eyni müştəri, eyni giriş şəbəkəsi, eyni fayl, eyni TLS konfiqurasiyası, eyni tətbiq hostu. Hər yol üzrə ötürməni iki dəfə işlədin və ümumi vaxtı, uğursuzluq sayını və cavabdehliyi qeyd edin, əlaqəsiz sürət testinin nəticəsini deyil.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Bu rəqəmlər bağlantı qurulumunu ötürmə vaxtından ayırır, bu da vacibdir, çünki iki yol adətən şifrə xərcində deyil, gediş-dönüş gecikməsində və MTU-da fərqlənir. TLS işi hər iki dizaynda son nöqtələrdə baş verir və tunel inkapsulyasiya, fərqli marşrut və bəlkə daha yüklü şlüz əlavə edir. Əgər tunel yolu daha uzundursa və ya şlüzü yüklüdürsə, fərq yola aiddir, şifrələmə sözünə deyil.

Xidmətin həqiqətən ehtiyac duyduğu giriş siyasətini seçin, sonra ölçülmüş fərqin onu dəyişməyə dəyər olub-olmadığına qərar verin. Açıq yönləndirmə açıq internet üçün nəzərdə tutulmuş xidmətə uyğundur: mənbə məhdudiyyətləri, yenilənmiş TLS və qarşısında monitorinq ilə. Yalnız tunel girişi istifadəçiləri artıq qeydiyyatdan keçmiş daxili alətə uyğundur, bir şərtlə ki, şlüz marşrutlaşdırması və tətbiq icazələri bütün LAN-dan dar olsun.

Dizaynı bitmiş adlandırmazdan əvvəl dörd şeyi təsdiqləyin: dinləyicinin hansı ünvana bağlandığını, paketi hansı qaydanın və ya marşrutun qəbul etdiyini, qayıtma yolunun müştərinin həqiqi ünvanından işləyib-işləmədiyini və böyük yüklərin MTU-dan sağ çıxıb-çıxmadığını. Bunların hər biri üçün yuxarıda bir əmr var və heç birinə «təhlükəsiz» sözü və ya buraxılış qrafiki cavab vermir.