VPN sitesinden gelen 403 neden proxy hatası değildir
Kaynaktan gelen 403, reddedilen CONNECT ve 407 meydan okuması farklı sınırları işaretler. Önce proxy'nin çıkış yolunu tarayıcının VPN adresiyle karşılaştırın.
Kullanıcılar VPN'i kapatır, dahili bir sitede 403 ile karşılaşır ve proxy'nin bozuk olduğunu bildirir. Bu sayfayı üç ayrı şey üretebilir: kaynak isteği reddetti, yönlendirici proxy tüneli açmayı reddetti veya proxy kendi kimlik bilgilerini talep etti. Bunların her biri farklı bir soruya doğru yanıttır ve hepsini tek bir genel hata sayfasında düzleştirmek elinizdeki tek kanıtı yok eder. Reddi, onu üreten bileşene göre ayırın, ardından her bileşenin gerçekte kullandığı ağ yolunu karşılaştırın.
403'ü üreten bileşeni adlandırın
HTTP durum kodu onu gönderen tarafa aittir. Kaynak 403 döndürdüğünde isteği ayrıştırmış ve çağıranın kaynağa sahip olmayabileceğine karar vermiştir; bu bir yetkilendirme yanıtıdır, taşıma sorunu değildir. Yönlendirici proxy bir CONNECT'e 403 yanıtladığında tüneli hiç inşa etmeyi reddetmiştir ve yukarı akışta hiçbir şeyle temasa geçilmemiştir. 407 yanıtladığında kendi kimlik bilgilerini ister; bunların uygulamanın oturum açmasıyla hiçbir ilgisi yoktur.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 bu rolleri, proxy'ye özgü meydan okuma dahil tanımlar. Gövdeyi okumadan önce yanıtın kendi durumunu ve varsa Proxy-Authenticate başlığını okuyun, çünkü dostça bir HTML hata sayfası genellikle hangi bileşenin yazdığını gizler.
Bir CONNECT tünelinin bayt aktarımından sakladığı şey
Bir proxy CONNECT'e 200 döndürdüğünde bayt aktarıyordur ve tarayıcı kaynakla kendi TLS oturumunu sürdürür. Bu nedenle bayt aktaran bir proxy o oturumun içindeki şifreli 403'ü okuyamaz ve hiçbir zaman reddin yazarı olmaz. Tünel açılmadan önceki bir ret, bir katman aşağıda üretilen tamamen farklı bir olaydır.
TLS'i sonlandıran ters proxy farklı bir konumdadır: TLS sınırına sahiptir, HTTP'yi ayrıştırır ve yanıtları meşru şekilde yeniden yazabilir veya yakalayabilir. Bu yetenek bir yapılandırma seçimidir, genel olarak proxy'nin bir özelliği değildir ve uygulamanın erişim politikasını atlama yetkisi vermez. Yanıtı okumak bir yetenektir; çağıranın neyi görebileceğine karar vermek kaynağın işi olarak kalır.
Pratik sonuç, bir 403'ü yorumlamadan önce üç biçimden hangisini çalıştırdığınızı bilmeniz gerektiğidir. Bir akış proxy'sine HTTP denetim kuralları eklemek ona görünürlük kazandırmaz ve bir bayt aktarımının kaynak reddini açıklamasını beklemek sizi yanlış günlüğe yönlendirir.
Proxy'nin çıkış yolunu tarayıcının tünel adresiyle karşılaştırın
VPN'e bağlı bir tarayıcı ayrı bir proxy sunucusunu otomatik olarak o tünele taşımaz. Kaynak proxy'nin çıkış adresini görür ve proxy hâlâ yerel varsayılan rotadan çıkıyorsa korunan site, güvenilmesi için hiç yapılandırılmamış bir adres görür. Dizüstü bilgisayardaki iç VPN adresi o kaynak için görünmez. Bu, çalışan bir tünelin diğer herkese doğru davranan bir siteden hâlâ 403 vermesinin en yaygın nedenidir.
Adreslerin karışmaması için iki yolu ayrı ayrı test edin.
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İlk istek kaynağın sizin adresinize ne yanıt verdiğini, ikincisi proxy'nin adresine ne yanıt verdiğini gösterir. Eşleşen bir 403 çifti kaynağın yetkilendirme kurallarına işaret eder; 200'ün ardından gelen 403 proxy yoluna işaret eder. VPN havuzunun dahil olduğunu varsaymak yerine kural kümesinin gerçekte hangi kaynak adreslerini kabul ettiğini kaynağın sahibine sorun.
Her sınırı onu yalıtan bir istekle test edin
Proxy katmanını, uygulama nedenleriyle reddedemeyeceği bir şey isteyerek yalıtın. Proxy'nin erişmesine izin verilen bir ana bilgisayara CONNECT, çıktı atılarak, tünel kabulünün baştan çalışıp çalışmadığını söyler.
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 için 200 ve ardından bir TLS el sıkışması yazdırırsa proxy kabulü yerindedir ve sonraki 403 kaynaktan gelmiştir. 407 yazdırırsa --proxy-user ile proxy kimlik bilgilerini verin ve site hakkında herhangi bir sonuca varmadan önce yineleyin. CONNECT satırında 403 yazdırırsa incelenecek sınır proxy'nin kendi izin listesidir ve uygulama bu işe karışmaz.
Kimlik bilgilerini kabuk geçmişinden ve yapıştırılmış dökümlerden uzak tutun. Komut satırına yazılan bir proxy parolası diğer yerel kullanıcılar tarafından görülebilir ve kimlik bilgileriyle yakalanmış bir CONNECT izi hiç iz olmamasından daha kötüdür.
Sayfayı yeniden yazmak yerine kararı okunabilir tutun
Hangi bileşenin reddettiğini bildiğinizde o yanıtı koruyun. Kaynak 403'ünü 504 zaman aşımı olarak yeniden etiketleyen veya onu bir başarı sayfasıyla değiştiren bir ters proxy, yetkilendirme kararını bir kullanılabilirlik hikâyesinin arkasına saklar ve bir sonraki yanıtlayanı yanlış ekibe gönderir. Özel hata sayfaları durumu koruyup bağlam eklediğinde iyidir.
Önbellekleme de aynı özeni hak eder. RFC 9111, paylaşılan önbelleklerin yanıtları nasıl yeniden kullanabileceğini düzenler ve bir çağıran için üretilen ret, izinmiş gibi bir başkasına verilmemelidir. Ret yanıtları saklanıyorsa bunları özel ve sınırlı tutun ve yalnızca yukarı akış trafiğini azaltmak için asla genel bir tazelik kuralı eklemeyin.
Bileşeni, ürettiği durumu ve kaynağın gördüğü kaynak adresini adlandıran yazılı bir kararla bitirin. Tam isteği, yürürlükteki proxy ayarlarını ve zamanı kaydedin; böylece bir sonraki rapor aynı kanıtlarla eşleştirilebilir, bellekten yeniden türetilmek zorunda kalmaz. Bu kayıt bir sonraki rapora saniyeler içinde yanıt verir ve aynı 403'ün yeniden VPN kesintisi olarak teşhis edilmesini önler.