UDP-ni ISP bloklayır, yoxsa tunelin içindəki tətbiq?

Kimsə VPN-in "UDP-ni blokladığını" bildirir və bu ifadə iki tamamilə fərqli iddianı gizlədir. Biri giriş şəbəkəsinin görə bildiyi nəqlə, digəri isə tunelin içində şifrəsi açıldıqdan sonra tətbiqin paketlərinə aiddir. Şifrələnmiş tunel heç bir açar olmadan kənardan filtrlənə bilər və daxili UDP tətbiqi filtrasiya ilə heç bir əlaqəsi olmayan səbəblərdən uğursuz ola bilər. Dəlil toplamazdan əvvəl hansı iddianı sınaqdan keçirdiyinizi müəyyənləşdirin.

İki başlıq, bir söz

NAT-traversal IPsec quraşdırmasında xarici paket iki VPN son nöqtəsi arasında ünvanlanmış UDP-dir, adətən 4500 portunda. Bunun içində şifrələnmiş yük tunelin ötürdüyü hər şeyi daşıyır; bu da özü TCP və ya UDP ola bilər. Beləliklə, UDP sözü iki dəfə, fərqli məna və fərqli görünürlüklə çıxır.

Ara şəbəkə xarici başlığı görür, daxili başlıqdan isə heç nə. O, xarici axına icazə verə, onu formalaşdıra və ya ata bilər və bunun üçün heç nəyin şifrəsini açmağa ehtiyac duymur. Bu asimmetriya iki iddianın qarışdırılmasının bütün səbəbidir: eyni söz həm şəbəkənin filtrlədiyini, həm də tətbiqin göndərdiyini təsvir edir. Bir tapıntı qeyd edəndə sözün yanına qatı yazın və qarışıqlıq əsasən yox olur.

Daxili başlıq yalnız qəbul edən son nöqtədə, şifrə açıldıqdan sonra görünür olur. Bundan sonra paket marşrutlara, siyasətə və son nöqtənin öz filtrasiyasına tabe olaraq hər hansı digəri kimi yönləndirilir. Bunlar müxtəlif qurğuların verdiyi ayrı qərarlardır.

Şəbəkə hələ nə görə bilər

Şifrələmə yükü və daxili nəql başlığını gizlədir, axının mövcudluğu faktını yox. Son nöqtə ünvanları, portlar, paket ölçüləri və vaxtlama görünən qalır və bunlar trafiki evristik olaraq təsnif etmək və ya konkret təyinatı bloklamaq üçün kifayətdir.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Birinci tutma fiziki interfeysdə xarici axını, ikincisi tunel interfeysində daxili axını göstərir. İkisini eyni vaxtda işə salmaq suala birbaşa cavab verir: əgər xarici axın varsa və daxili yoxdursa, tətbiq tunelə heç nə göndərməyib. Əgər hər ikisi varsa və heç nə qayıtmırsa, problem tuneldən kənardadır: təyinatda və ya qayıdış yolunda.

RFC 3948 xarici UDP inkapsulyasiyasını müəyyən edir, ESP spesifikasiyası isə onun içindəki qorunan düzülüşü müəyyən edir. Heç bir sənəd giriş şəbəkəsinin xarici axını keçirəcəyini vəd etmir; buna görə daxili barədə hər hansı nəzəriyyədən əvvəl xarici kortejdə əlçatanlıq testi aparmağa dəyər. Bloklanmış xarici kortej heç vaxt formalaşmayan tunel yaradır, formalaşıb sonra bir tətbiqi itirən tunel yox.

Niyə işləyən tunelin içində bir UDP tətbiqi uğursuz olur

Veb tətbiqini daşıyan, lakin UDP tətbiqini daşımayan tunelin bir neçə inandırıcı izahı var və ISP-in daxili protokolu filtrləməsi birinci deyil. Ən çox rast gəlinən əhatədir: iki tətbiq eyni tunelə birlikdə girmir, çünki UDP təyinatının marşrutu yoxdur və ya müştərinin split-tunnel qaydaları onu istisna edir.

İkincisi son nöqtədir. Protokol siyahısına icazə verən VPN serveri, təyinat firewall-u və ya gözlənilən portda heç vaxt dinləməyən xidmət — hamısı şəbəkə blokuna bənzəyən bir timeout yaradacaq.

Üçüncüsü paket ölçüsüdür. UDP tətbiqləri çox vaxt veb sorğusundan daha böyük datagramlar göndərir və inkapsulyasiya istifadə oluna bilən MTU-nu azaldır, ona görə işləyən əl sıxışmadan sonra ilk tam ölçülü yükdə sükut gələ bilər. Bu nümunəni blok kimi oxumaq asandır, çünki kiçik paketlər keçir, böyüklər isə yox olur. Sürətli MTU yoxlaması bunu bir dəqiqədən az müddətdə həll edir və cavab adətən şəbəkə filtri deyil, daha kiçik yük və ya düzəldilmiş MSS olur.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Birinci əmr böyük paketin fraqmentasiya söndürülmüş halda yoldan keçib-keçmədiyini yoxlayır və MTU problemini tez üzə çıxarır. İkincisi kiçik, məhdud UDP axını göndərir və itki ilə jitter barədə məlumat verir. Başlayıb sonra dayanan axın bloka deyil, ölçüyə işarə edir.

Protokolu deyil, qatı bildirin

Tapıntını üç formadan biri ilə yazın: xarici çatdırılma uğursuz oldu, daxili yönləndirmə uğursuz oldu və ya tətbiq uğursuz oldu. Hər birinin fərqli sahibi var və onları qarışdırmaq bileti yanlış komandaya göndərir.

Lokal portu dəyişmək uzaq tərəfdə uyğun dinləyici yarada bilməz, ona görə kömək edirmiş kimi görünən müştəri tərəfli keçici həll adətən ilkin təyinatın səhv olduğuna dəlildir. Eyni şəkildə, təqdim edilən alternativ profil əlçatanlıq barədə nəsə sübut edir, tətbiqin düzgün konfiqurasiya olunması barədə isə heç nə.

Nəticə çıxarmanı müşahidədən də ayrı saxlayın. Trafik təhlili axının nə olduğunu şifrəsini açmadan təklif edə bilər və bu faydalı tapıntıdır, lakin daxili başlığı oxumaqla eyni iddia deyil. Əlində hansının olduğunu göstərin.