HAProxy 302 xüsusi tətbiqə: ikinci keçidi kim açır?

Kimsə açıq HAProxy hostunu daxili tətbiqə yönəldir və brauzerin niyə davam edə bilmədiyini soruşur. Proksi öz VPN-i ilə tətbiqə çatır, yönləndirmə Location başlığını qaytarır və brauzer sonra yalnız tunelin içində mövcud olan ünvana cəhd edir. Xaricdən səhifə sadəcə donur. Qərar ikinci bağlantını hansı tərəfin açması ilə bağlıdır və yönləndirməni backend-dən ayıran da elə budur.

Konfiqurasiyada oxşar görünən iki yol

Yönləndirmə mübadiləni cavabla bitirir. Müştəri Location-u oxuyur və harada yerləşirsə oradan yeni sorğu başladır, yəni sizin heç vaxt nəzarət etmədiyiniz şəbəkədən. Proksi artıq iştirak etmir. Sonrakı hər şey müştərinin öz DNS-indən, marşrutundan və etimadından asılıdır, ona görə nəticə istifadəçinin brauzeri harada açdığına görə dəyişir:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Proksinin backend-i ikinci mərhələni server tərəfində saxlayır. Proksi onu artıq malik olduğu yol ilə açır və müştəri bir açıq adla danışmağa davam edir. Tunel düşərsə, müştəri davam edə bilmədiyi URL əvəzinə xəta alır. Bu fərq nasazlığı diaqnoz edilə bilən edən şeydir, çünki xəta jurnalların olduğu yerdə görünür:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy-nin yönləndirmə sənədləşməsi məhz bu xətti çəkir: müştəriyə yönləndirmə ilə cavab vermək sorğunu backend-ə ötürməkdən fərqli bir hərəkətdir. İki direktiv konfiqurasiya faylında bir neçə sətir aralıda yerləşir və tamamilə fərqli davranır. Biri sorğunu bitirir, digəri proksiyə məxsus ikinci bir sorğu başladır.

Brauzerin ehtiyac duyduğu və serverin VPN-inin ona vermədiyi şey

Brauzerin öz sorğusuna bəlkə də malik olmadığı dörd şey lazımdır: xüsusi ad üçün DNS cavabı, həmin ünvana marşrut, dinləyən xidmətə çatmaq icazəsi və həmin xidmətin təqdim etdiyi sertifikata etimad. Proksi hostu dördünə də öz tuneli ilə malikdir. Onların heç biri heç vaxt həmin tuneldə olmamış müştəriyə keçmir, çünki tunel hostun xassəsidir, URL-in deyil.

Bu boşluq demək olar işləyir simptomunu izah edir. Birinci sorğu uğurlu olur, ünvan sətri dəyişir, sonra proksi bütün müddət sağlam olduğu halda bağlantı donur və ya uğursuz olur. Proksi konfiqurasiyasında heç nə sınmayıb və onu düzəltmək 10.40.0.20-yə yolu olmayan müştəriyə kömək etmir. Ya müştəri marşrut alır, ya da proksi bağlantını onun adından qurmalıdır.

Yalnız proksi tətbiqə çata bildikdə

Yönləndirmə əməliyyatını silin və həmin sorğuları xüsusi ünvana yönələn backend-ə göndərin. Frontend açıq adını saxlayır, backend isə sorğunun həqiqətən hara getdiyini qərar verir. Müştərinin yolunda heç nə dəyişmir, çünki proksi hədəfi təsvir etməyi dayandırır və özü hədəf olur. Daxili 8080 portunda qəsdən dinləyən tətbiq üçün server bloku qısadır:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Bu bloku proksinin marşrut cədvəli haqqında bəyanat kimi oxuyun: 10.40.0.20 proksi hostunun özündən əlçatan olmalıdır, burada bu, defolt marşrutla deyil, VPN interfeysi ilə deməkdir. check açar sözü yalnız həmin marşrutun nə etdiyini bildirir və sağlamlıq yolu tətbiqdə mövcud olmalıdır, əks halda hər yoxlama serveri söndürülmüş kimi qeyd edir. Uğurlu yoxlama müştəri haqqında heç nə sübut etmir və backend-dən kimin istifadə edə biləcəyini qərar verən siyasəti əvəz etmir.

Bu fraqment tam frontend deyil. Dinləyicini, autentifikasiyanı, icazə verilən host və yol seçimini və tətbiqə ümumiyyətlə kimin çata biləcəyini qərar verən qaydanı saxlayın. Backend protokolunu da uyğunlaşdırın, çünki HTTPS backend sertifikat yoxlaması və server kimliyi konfiqurasiyası tələb edir və bu yoxlamanı atlamaq xüsusi bağlantını yoxlanılmamış birinə çevirir.

Qələbə elan etməzdən əvvəl geri dönüş yolunu hər iki istiqamətdə təsdiqləyin. Tətbiq indi proksidən gələn bağlantı görür, ona görə jurnalları və hər hansı müştəri ünvanı metadatası başqa cür təşkil etməsəniz proksini təsvir edir. Kimliyin və yönləndirilən ünvanların necə idarə olunduğunu qərar verin və qərarı fərz etmək əvəzinə sınaqdan keçirin.

Tətbiqin öz yönləndirmələri hələ də içəri baxır

Birinci sorğunu ötürmək inteqrasiyanın yalnız yarısıdır. Tətbiq mütləq yönləndirmələr, əl ilə kodlanmış resurs URL-ləri və ya daxildə bildiyi ada bağlanmış kukilər yaya bilər və bunların hər biri brauzeri çata bilmədiyi ünvana qaytarır. Daxili ada baxan Location başlığı ilkin problemlə eyni görünür, buna görə də səhvən proksi nasazlığı kimi diaqnoz edilir.

Tətbiqin sənədləşdirilmiş xarici URL-ini və proksi seçimlərini qeyd edin, sonra Host başlığını virtual host və sertifikat gözləntiləri ilə uyğunlaşdırın. Daxili ada bağlanmış kuki açıq ad vasitəsilə geri qayıtmayacaq və ardınca gələn giriş dövrəsi autentifikasiya xətası kimi oxunur. Əvvəlcə xarici URL-i dəyişin, təmiz brauzer profilindən yenidən sınayın və yarım köçürülmüş parametrlərin uğurlu giriş və dərhal ölən sessiya yaradacağını gözləyin.

Yönləndirilmiş metadataya yalnız təyin edilmiş proksidən etibar edin. Hər hansı müştərinin qura bildiyi başlıq heç vaxt avtorizasiya dəyəri olmamalıdır, əks halda proksi zəng edənin başqasının kimliyini iddia etməsi üçün vasitəyə çevrilir. Bu qayda yönləndirmə sualından asılı deyil və hər sonrakı yenidən dizayna dözür.

Əslində hansı dizayna sahib olduğunuzu qərar verin

Əgər hər istifadəçinin artıq icazəli VPN çıxışı varsa, xüsusi URL-ə yönləndirmə qəsdən seçilmiş dizayn ola bilər. Bu tələbi fərz etmək əvəzinə açıq şəkildə təsdiqləyin, çünki iki dizayn tamamilə fərqli populyasiyalara xidmət edir. Onlardan biri otel şəbəkəsindən heç işləmir, digəri isə tətbiqi açıq URL-i yükləyə bilən hər kəsə açır. Bu fərq dizayn qeydinə aiddir.

Yoxlamanı istifadəçilərin şəbəkəsindəki maşından aparın və brauzerin etdiyi hər keçidi izləyin, yalnız ilk cavabı deyil. Ünvan sətrini və hər sonrakı sorğunu göz altında saxlayın, çünki resurs etiketində bir mütləq URL birinci keçidin keçdiyi axını pozmaq üçün kifayətdir. Giriş açıq ad vasitəsilə işləməlidir və rədd edilməli resurslar rədd edilmiş qalmalıdır.

Əks proksini yayımlamaq ayrı bir giriş qərarıdır, proksin öz VPN-inin açıq URL-ini yükləyə bilən hər kəsə şəffaf uzantısı deyil. Diaqramda ikisi oxşar görünür və onlar kimin içəri buraxıldığı ilə fərqlənir. Bu sualı yerləşdirmədən sonra qərar vermək daxili tətbiqin təsadüfən açıq tətbiqə çevrilməsi yoludur.

Hansını qurduğunuzu və niyə qurduğunuzu yazın. Konfiqurasiyaya toxunan növbəti şəxs digərini fərz edəcək. Rahatlıq üçün əlavə edilmiş bir yönləndirmə ilkin nasazlığı yenidən yaratmaq üçün kifayətdir və simptom indicə düzəltdiyinizlə tam eyni görünəcək.