VPN saytından gələn 403 niyə proksi nasazlığı deyil

İstifadəçilər VPN-i söndürür, daxili saytda 403 alır və proksinin xarab olduğunu bildirir. Bu səhifəni üç ayrı şey yarada bilər: mənbə sorğunu rədd etdi, irəli proksi tuneli açmaqdan imtina etdi və ya proksi öz etimad məlumatlarını tələb etdi. Bunların hər biri başqa suala düzgün cavabdır və onları bir ümumi nasazlıq səhifəsinə düzəltmək əlinizdəki yeganə sübutu məhv edir. Rəddi onu yaradan komponentə görə ayırın, sonra hər komponentin həqiqətən istifadə etdiyi şəbəkə yolunu müqayisə edin.

403-ü yaradan komponenti adlandırın

HTTP status kodu onu göndərən tərəfə aiddir. Mənbə 403 qaytardıqda sorğunu təhlil edib zəng edənin resursa sahib olmaya biləcəyinə qərar verir ki, bu da nəqliyyat problemi deyil, səlahiyyət cavabıdır. İrəli proksi CONNECT-ə 403 cavabı verdikdə tuneli ümumiyyətlə qurmaqdan imtina edir və yuxarıda heç bir yerə müraciət olunmur. 407 cavabı verdikdə isə öz etimad məlumatlarını istəyir ki, bunun tətbiqin girişi ilə heç bir əlaqəsi yoxdur.

RFC 9110 bu rolları, o cümlədən proksiyə xas çağırışı müəyyən edir. Gövdəni oxumazdan əvvəl cavabın öz statusunu və hər hansı Proxy-Authenticate başlığını oxuyun, çünki dostyana HTML xəta səhifəsi adətən onu hansı komponentin yazdığını gizlədir.

CONNECT tunelinin bayt ötürücüsündən gizlətdiyi şeylər

Proksi CONNECT-ə 200 qaytardıqdan sonra baytları ötürməyə başlayır və brauzer mənbə ilə öz TLS sessiyasını saxlayır. Buna görə bayt ötürən proksi həmin sessiyadakı şifrələnmiş 403-ü oxuya bilmir və heç vaxt rəddin müəllifi olmur. Tunel açılmazdan əvvəlki imtina isə bir qat aşağıda yaranan tamamilə fərqli hadisədir.

TLS-i sonlandıran tərs proksi fərqli mövqedədir: TLS sərhədinə sahibdir, HTTP-ni təhlil edir və cavabları qanuni şəkildə yenidən yaza və ya tuta bilər. Bu qabiliyyət konfiqurasiya seçimidir, ümumiyyətlə proksinin xassəsi deyil və tətbiqin giriş siyasətini yan keçməyə icazə vermir. Cavabı oxumaq bacarıqdır; zəng edənin nəyi görə biləcəyinə qərar vermək isə mənbənin işi olaraq qalır.

Praktik nəticə budur ki, 403-ü şərh etməzdən əvvəl üç formadan hansını işlətdiyinizi bilməlisiniz. Axın proksisinə HTTP yoxlama qaydaları əlavə etmək ona görünürlük vermir və bayt ötürücüsündən mənbə rəddini izah etməsini gözləmək sizi səhv jurnala baxmağa göndərəcək.

Proksinin çıxış yolunu brauzerin tunel ünvanı ilə müqayisə edin

VPN-ə qoşulmuş brauzer ayrıca proksi serverini avtomatik olaraq həmin tunelə köçürmür. Mənbə proksinin çıxış ünvanını görür və proksi hələ də yerli standart marşrutla çıxırsa, qorunan sayt heç vaxt etibar etmək üçün konfiqurasiya edilmədiyi bir ünvan görür. Noutbukdakı daxili VPN ünvanı həmin mənbə üçün görünməzdir. Bu, işləyən tunelin hər kəs üçün düzgün davranan saytdan hələ də 403 verməsinin ən çox yayılmış səbəbidir.

Ünvanların qarışmaması üçün iki yolu ayrı-ayrılıqda yoxlayın.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Birinci sorğu mənbənin sizin ünvanınıza nə cavab verdiyini, ikincisi proksinin ünvanına nə cavab verdiyini göstərir. Uyğun gələn iki 403 mənbənin səlahiyyət qaydalarına işarə edir; 200-dən sonra gələn 403 proksi yoluna işarə edir. VPN hovuzunun daxil olduğunu güman etmək əvəzinə mənbə sahibindən qayda dəstinin hansı mənbə ünvanlarını həqiqətən qəbul etdiyini soruşun.

Hər sərhədi onu təcrid edən sorğu ilə yoxlayın

Proksi qatını tətbiq səbəbləri ilə rədd edə bilməyəcəyi bir şey istəməklə təcrid edin. Proksisin çatmağa icazəsi olan hosta CONNECT, çıxış atılmaqla, tunel qəbulunun ümumiyyətlə işləyib-işləmədiyini bildirir.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Bu, CONNECT üçün 200 və sonra TLS əl sıxma çap edirsə, proksi qəbulu qaydasındadır və sonrakı 403 mənbədən gəlib. 407 çap edirsə, --proxy-user ilə proksi etimad məlumatlarını verin və sayt haqqında hər hansı nəticə çıxarmazdan əvvəl təkrarlayın. CONNECT sətrində 403 çap edirsə, yoxlanmalı sərhəd proksisin öz icazə siyahısıdır və tətbiq burada iştirak etmir.

Etimad məlumatlarını shell tarixçəsindən və yapışdırılmış transkriptlərdən kənarda saxlayın. Əmr sətrinə yazılan proksi parolu digər yerli istifadəçilərə görünür və etimad məlumatları ilə tutulmuş CONNECT izi heç iz olmamasından pisdir.

Səhifəni yenidən yazmaq əvəzinə hökmü oxunaqlı saxlayın

Hansı komponentin imtina etdiyini bildikdən sonra o cavabı qoruyun. Mənbədən gələn 403-ü 504 fasiləsi kimi yenidən etiketləyən və ya onu uğur səhifəsi ilə əvəz edən tərs proksi səlahiyyət qərarını əlçatanlıq hekayəsinin arxasında gizlədir və növbəti cavabdehi səhv komandaya göndərir. Fərdi xəta səhifələri statusu saxlayıb kontekst əlavə etdikdə yaxşıdır.

Keşləmə də eyni qayğıya layiqdir. RFC 9111 paylaşılan keşlərin cavabları necə təkrar istifadə edə biləcəyini tənzimləyir və bir zəng edən üçün yaranan rədd icazə kimi başqasına verilməməlidir. Rədd cavabları ümumiyyətlə saxlanılırsa, onları şəxsi və məhdud saxlayın və yalnız yuxarı axın trafikini azaltmaq üçün heç vaxt ictimai təzəlik qaydası əlavə etməyin.

Komponenti, onun yaratdığı statusu və mənbənin gördüyü mənbə ünvanını adlandıran yazılı hökmlə bitirin. Dəqiq sorğunu, qüvvədə olan proksi parametrlərini və vaxtı qeyd edin ki, növbəti hesabat yaddaşdan yenidən çıxarılmadan eyni sübutlarla tutuşdurula bilsin. Bu qeyd növbəti hesabata saniyələr içində cavab verir və eyni 403-ün yenidən VPN nasazlığı kimi diaqnoz edilməsinin qarşısını alır.