Şube tarayıcısından proxy’ye: iki bağlantı, iki yol
Tarayıcı proxy’nin dinleyicisiyle, proxy de siteyle konuşur. İki bağlantıyı da yapılandırın ve bunları iki ayrı arıza olarak test edin.
Açık bir proxy’nin arkasındaki şube tarayıcısı iki bağlantı açar ve bunlar farklı nedenlerle başarısız olur. Birincisi tarayıcıdan proxy dinleyicisine, şube VPN’i üzerinden taşınır. İkincisi proxy’den web sitesine, proxy’nin kendi çözümleyicisi, yolu ve çıkış politikasıyla. Bunları tek akış sayan destek biletleri, insanları saatlerce yanlış cihaza gönderir. Her birini bilinçli kurun ve bu sırayla test edin.
Adım 1: iki akışı yazın
Tarayıcının doğrudan hedefi proxy dinleyicisidir, kullanıcının sonunda ziyaret ettiği her site değil. Bu tek cümle, bu tasarımdaki karışıklığın çoğunu çözer.
branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> websiteFarklı kaynaklar, farklı yollar, farklı izinler. Krokiyi değişiklik kaydında tutun, çünkü sonraki her kontrol onun iki yarısından birine başvurur.
Adım 2: tarayıcıya dinleyiciye giden bir yol verin
Proxy ana bilgisayar adını, dinleyici bağlantı noktasını, kimlik doğrulama gereksinimlerini ve izin verilen şube kaynaklarını kaydedin. Bu liste ilk akışın kabul ölçütüdür ve hem özel ad çözümlemesini hem de tünel yolunu içermelidir.
Sınırsız bir proxy’yi internete yayımlamak yerine amaçlanan hizmet için dar bir ağ kuralı uygulayın. Amaçlanan istemcilerinin ona desteklenen bir yolu olduğunda proxy iç ağda kalabilir.
Adım 3: yalnızca yol tablosunu değil, tarayıcıyı yapılandırın
Tarayıcının proxy ayarını, bir PAC dosyasını veya kuruluşun yönetilen keşif mekanizmasını kullanın. Normal web sitesi paketlerini bir yolla proxy adresine göndermek, tarayıcının proxy protokolünü konuşmasını sağlamaz; bu şeffaf müdahaledir ve başka bir ağ geçidi tasarımına aittir.
Hangi uygulamaların ayara uyduğunu yazın. Posta istemcileri, güncelleyiciler ve oyunlar çoğu zaman uymaz ve basit yolu kullanmaya devam eder.
Adım 4: proxy’nin ileri bağlantısını kanıtlayın
Proxy’nin kendi çözümleyicisine ve siteye izin verilen bir yola ihtiyacı vardır; ayrıca internet sınırının gerektirdiği güvenlik duvarı veya çeviri politikası da gerekir. Dinleyiciye ulaşan bir tarayıcı bunların hiçbirini kanıtlamaz. İkinci akışı proxy’nin kendisinden, kullanıcının bildirdiği aynı hedef ve bağlantı noktasıyla test edin.
HTTPS için, CONNECT istenen hedefe bir tünel açar. Normal yönlendirme şifresi çözülmüş sayfayı proxy’ye vermez ve incelemeyi doğaçlama yapmak için sertifika doğrulamasını kapatmak çözüm değildir.
Adım 5: dört arızayı ayırt edin
Proxy kimlik doğrulama isteği, dinleyiciden gelen bir 407’dir. Reddedilen CONNECT, proxy’de bir politika kararıdır ve genellikle kendi durumu ve günlük satırı vardır. Başarısız ileri bağlantı, proxy’nin hedefe karşı günlüğe kaydettiği bir zaman aşımı veya sıfırlama gibi görünür. Web sitesi yanıtı, iki bağlantının da çalıştığı ve sorunun kaynakta olduğu anlamına gelir.
VPN başarısız oldu özetini değil, gözlemlediğiniz sınırı bildirin.
Adım 6: kapsamı belirleyin ve yedek planı yapın
Proxy veya tünel kullanılamadığında ne olacağına karar verin ve bu tasarımın hangi trafiği kapsadığını açıkça söyleyin. Proxy ayarına uyan istemcilerden web erişimi taşır; posta, rastgele cihaz protokolleri veya yapılandırmayı yok sayan yazılım taşımaz.
Tasarımı daha fazla istemciye genişletmeden önce onaylanmış bir plan kapsamında gerekli tarayıcı işlemini ve gerekli bir reddi doğrulayın.