Korporativ VPN-də konteyner HTTPS-i donur? DTLS ayağını yoxlayın

Korporativ VPN arxasındakı konteyner daxilində DNS həll olunur, giriş səhifəsi yüklənir, sağlamlıq son nöqtəsi cavab verir, sonra HTTPS sorğusu vaxt aşımına qədər donur. İmici yenidən qurmaq və proksi dəyişənlərini dəyişmək heç nə etmir, çünki sıradan çıxan hissə imicdə deyil. Müştəri bir nəqliyyat üzərində autentifikasiya edir, kütləvi məlumatı başqa biri üzərində ötürür və yalnız ikincisi pozulub.

İki nəqliyyat, bir qarışıq simptom

TLS əsaslı korporativ müştəri adətən adi TLS bağlantısı üzərində autentifikasiya edir, sonra sessiya üçün UDP əsaslı ikinci məlumat kanalını razılaşdırır. Həmin ikinci ayaq işlədikdə ötürmə qabiliyyəti və gecikmə yaxşılaşır. O filtrələndikdə və ya yoldan keçə bilmədikdə, kütləvi ötürmədən əvvəlki hər şey uğurlu olur və ötürmənin özü dayanır, yəni yuxarıdakı mənzərə tam budur.

Konteyner o razılaşmanı dəyişmir; xarici paketlərin keçdiyi yolu dəyişir. Host konteyner axınını tərcümə edir, ona görə UDP veraqramları müştərinin lokal soketindən fərqli mənbə portundan çıxır və qurulmuş TCP axınından qat-qat qısa taymerlə bitən tərcümə qeydindən keçərək qayıdır. Tunel hostda işləyib konteynerdə uğursuz olursa, tətbiqi günahlandırmadan əvvəl həmin iki axını müqayisə edin. Bu müqayisə hər hansı imic yenidənqurmasından çox şey həll edir.

İntuisiyayla deyil, təcrübə ilə qərar verin

Ən ucuz təcrübə UDP məlumat kanalını söndürüb sorğunu təkrarlayır. Masaüstü sarğı yerinə əmr sətri müştərisindən istifadə edin ki, bayraq həqiqətən tətbiq olunsun: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Donmuş sorğu indi tamamlanırsa, DTLS ayağı problem idi və qalanı səs-küy idi.

Nəticəni eyni konteynerdən hər iki istiqamətdə təsdiqləyin: bayraqla bir kütləvi sorğu, bayraqsız bir sorğu. Bayrağı izləyən davranış dəyişikliyi sübutdur; sonda yüklənən səhifə deyil.

Bayraq düzəldirsə, səbəbini müəyyən edin

Üç şərt eyni simptomu yaradır və fərqli cavablar tələb edir. Yol UDP-ni tamamilə filtrələyə bilər, bu da bayrağı həmin şəbəkə üçün düzgün daimi cavab edir. Yol UDP-yə icazə verib böyük veraqramları ata bilər, bu filtrə deyil, MTU-ya işarə edir. Ya da yol o qədər itkili ola bilər ki, UDP ayağı TCP-dən pis işləsin; bu, çatımlılıq deyil, tutum qərarıdır.

Müvəqqəti həlli sənədləşdirməzdən əvvəl onları ayırd edin. Filtrələmə hər paket ölçüsündə qalır, MTU problemləri yalnız həddən yuxarı görünür, itki isə təmiz donma kimi deyil, yenidən ötürmə və dəyişkən gecikmə kimi görünür. Hər test müştəri konfiqurasiyasını dəyişmədən səbəbi daraldır.

Müvəqqəti həlli saxlamazdan əvvəl paket ölçüsünü yoxlayın

Səbəb ölçüdürsə, tunel interfeysi yolun daşıya bilmədiyi paketləri qəbul edir və yük böyüdükcə problem istənilən nəqliyyatda qayıdır. İnterfeysləri müqayisə edin: hostda ip link show tun0, sonra şəbəkə seçimlərində qeyd olunan MTU-nu oxumaq üçün docker network inspect bridge. Daha az daşıyan tunel altında hələ 1500 baytda qalan konteyner körpüsü adi tapıntıdır.

Tunel daxilində parçalanmama testi ilə məlum yaxşı ölçüdən yuxarı doğru yoxlayın, sonra konteyner şəbəkəsinin MTU-sunu aşağı salın və ya tuneldə TCP MSS-i sıxın. Hər iki düzəliş çox vaxt UDP yolunu yenidən yararlı edir və bayraq ehtiyacını aradan qaldırır; filtrələmə səbəb deyilsə, bu daha yaxşı nəticədir.

Nəyə nə verməyə hazır olduğunuza qərar verin

Məlumat kanalı söndürüldükdə tunel yükünü TCP bağlantısı içində daşıyır. Təmiz yolda bu sadəcə daha yavaşdır; itkili yolda bir itirilmiş seqment arxasındakı hər şeyi gecikdirir və xarici yenidən ötürmə daxili ilə rəqabət edir. Bu mübadilə interaktiv inkişafa və kiçik API çağırışlarına uyğundur, kütləvi ötürmələrə və ya mobil keçidlərdə uzun sessiyalara zəif uyğun gəlir.

Hansı variantı seçsəniz də, tunelin sonda hansı nəqliyyatdan istifadə etdiyini və niyə olduğunu qeyd edin. Aylar əvvəl kiminsə əlavə etdiyi bayraqdan səssizcə asılı olan konteyner növbəti kəsintidir və onu sazlayan şəxs bayrağın filtrələmə üçün müvəqqəti həll, yoxsa MTU təcrübəsindən qalıq olduğunu bilməyəcək.