Korporativ VPN arxasında tətbiq sorğuları uğursuz olur, brauzer isə işləyir

Daxili portalı brauzerdə açırsınız və o yüklənir. Eyni hosta müraciət edən tətbiqi işə salırsınız və o, heç bir qatı adlandırmayan mesajla uğursuz olur. Tünel brauzeri daşıyır, yəni tünel ilk şübhəli deyil. Sorğunuzla xidmət arasında dörd şey dayanır və hər biri fərqli iz qoyur. Budur mənim izlədiyim sıra: VPN müştərisinin parametrlər səhifəsindən deyil, tətbiqin həqiqətən göndərdiyi sorğudan başlayaraq.

Tətbiqin həqiqətən göndərdiyi sorğuya baxın

Konfiqurasiyaya toxunmazdan əvvəl tətbiqə nə etdiyini söylədin. Proksinin açıq şəkildə söndürüldüyü bir sorğuluq tutma və sadə port testi sizə sonrakı addımların müqayisə edəcəyi iki başlanğıc xətti verir. Proksi söndürülmüş halda sorğu keçirsə, dörd qatdan üçü artıq bitib.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Son iki əmri eyni hədəfə qarşı işə salın və harada ayrıldıqlarını izləyin. İşləyən brauzer üstəgəl işləyən curl üstəgəl işləməyən tətbiq problemi tətbiqin əlavə etdiyi bir şeyə daraldır: proksi, transport və ya mesaj ölçüsü.

Tətbiq heç kimin qurmadığı proksini miras aldı

Əksər HTTP yığınları proksi konfiqurasiyasını standart olaraq əməliyyat sistemindən oxuyur. Korporativ VPN müştərisi çox vaxt onu öz giriş profilinə əlavə edir, buna görə sorğular tərtibatçının kodda heç vaxt qeyd etmədiyi proksidən çıxır. .NET-də standart handler IE/WinHTTP parametrlərindən götürür; Java -Dhttp.proxyHost oxuyur; Node-da kitabxana əlavə etməyincə daxili proksi dəstəyi yoxdur. Uğursuzluq nadir hallarda təmiz imtina olur, buna görə insanlar serverə baxmağa başlayır.

Test bir sorğuya başa gəlir: proksini bir handler-də açıq şəkildə söndürün və müqayisə edin.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Bu keçərsə, düzəliş tunelə deyil, tətbiqin konfiqurasiyasına aiddir. Layihədəki hər runtime üçün auditi təkrarlayın, çünki hər biri fərqli mənbə oxuyur və yalnız biri sınıq ola bilər.

Seçdiyiniz port siyasətin icazə verdiyi port deyil

Marşrutlaşdırılan host icazə verilmiş xidmət demək deyil. Korporativ siyasət adətən çıxan veb portlarına icazə verir, qalanını atır, buna görə 8080 və ya 1883 üzərindəki xidmət əlçatan olmur, 443 isə yaxşı işləyir. Brauzer burada heç nə sübut etmir: o, tərifinə görə 443 istifadə edir.

Həmin xidməti 443 arxasında yayımlayın və istisna istəməzdən əvvəl ona adla çatın. İstisna həqiqətən lazımdırsa, onu bir mənbə aralığına və bir hədəfə məhdudlaşdırın və bunu kiminsə şəxsi həlli deyil, xidmət tərifinin hissəsi kimi qəbul edin.

Yolun sıfırladığı xam TCP

Uzunömürlü xam TCP bağlantıları ən çaşdırıcı şəkildə uğursuz olan qatdır. Veb trafikinə icazə verən yol yenə də qeyri-adi çıxan TCP-ni sıfırlaya və ya yenidən yaza bilər, müştəri isə kəsinti kimi oxunan soket xətası bildirir. Mesajlaşma və hadisə xidmətləri adətən məhz bu cür şəbəkə üçün WebSocket transportu təqdim edir və keçid tunel dəyişikliyi deyil, müştəri seçimidir.

Transportu dəyişin, yenidən test edin və həmin keçiddə başqa heç nəyi dəyişməyin. Bu tək dəyişənli test sıfırlamanın yoldan, yoxsa xidmətdən gəldiyini söyləyir.

Yalnız böyük yüklərdə bağlanan bağlantılar

Uğurla keçən, sonra təxminən bir saniyə sonra ölən, ancaq gövdə böyük olanda ölən sorğu ortada bir yerdə ölçü həddinə işarə edir. Mesaj baytlarını sayan ara qat bağlantını köçürmənin ortasında sala bilər və müştəri gözləmə müddəti yerinə anormal bağlanma bildirir.

Yükü tətbiq qatında hissələrə bölün. Bunu MTU işindən ayrı saxlayın: tunelin paket ölçüsünü azaltmaq adi TCP sessiyaları sabit bayt sayında dayandıqda kömək edir, ara qatın çox böyük saydığı mesaj üçün isə heç nə etmir.

Dördünü bir keçiddə necə ayırd etmək olar

Üç müşahidə halların çoxunu həll edir. Uğursuzluq dərhal, yoxsa yalnız böyük gövdə ilə olur? Eyni sorğu proksi söndürülmüş halda keçirmi? Portu və ya transportu dəyişəndə nəticə dəyişirmi? Cavabları növbəti dəyişiklikdən əvvəl yazın, çünki korporativ VPN üstəgəl miras qalan proksi üstəgəl tətbiqin standart parametri sizə eyni anda üç ehtimal olunan səbəb verir.

Hər testdə bir dəyişən saxlayın və istifadə etdiyiniz hədəf hostu qeyd edin. Bu başlanğıc xətti olmadan növbəti şəxs dörd addımı yenidən əvvəldən təkrarlayır.