Satır içi vekil ve ICAP sorunları
Denetim uç noktasının reddettiği çağıranlar, göründükleri gibi olmayan kaynak adresleri ve indirilemeyen bir vekil CA sertifikası.
- Sürüm: 0.4
- Rol: admin_user
- Tür: sorun giderme
Denetim iki noktada bozulur: kabul (bu çağıran dinleyiciyle konuşabilir mi?) ve içerik (bu istek hiç denetlenebilir mi?). İkisi de arıza gibi okunan retler üretir.
Note
ICAP dinleyicisi eşini kimlik doğrulayamaz. CID'nin tümleştiği hiçbir SWG ürünü bir kimlik bilgisi ya da özel başlık alanı sunmaz; bu yüzden kabul yalnızca adrese dayanır ve kabul edilen bir eşe, iddia ettiği kullanıcıya kadar inanılır. Oradaki tek denetim olarak kaynak IP izin listesini görün — ve ona güvenmeden önce bir sonraki bölümü okuyun.
Belirtinizi bulun
| Gördüğünüz | Çalışma kitabı |
|---|---|
| SWG, denetim uç noktasından 401 ya da 403 alıyor | Denetim uç noktası çağıranı reddediyor |
| Her çağıran aynı docker köprü adresiyle geliyor | Kaynak adresleri göründükleri gibi değil |
| Bir izin listesi ya her çağıranı kabul ediyor ya hiçbirini | Kaynak adresleri göründükleri gibi değil |
| CA indirmesi başarısız oluyor ya da istemciler her yakalanan sitede uyarı veriyor | Vekil CA erişilebilir değil |
| Büyük ya da parçalı bir yükleme, denetlenmedi diye reddediliyor | Parçalı yüklemeler denetlenmez, reddedilir |
Kabul
Denetim uç noktası çağıranı reddediyor
Kabul sabit bir sırayla değerlendirilir: önce mTLS koşulu, sonra bearer API anahtarı, sonra ağ konumu. Hiçbir kiracıya çözümlenmeyen bir anahtar, anahtar yokmuş gibi işlenmek yerine doğrudan reddedilir — aksi halde anahtar sahibi kayıtları adını verdiği herhangi bir kiracıya atfedebilirdi.
Note
allowed_source_ips ve mtls_subject_dn 2026-08-29 tarihine kadar yazılıyor, gösteriliyor ama
hiçbir yerde okunmuyordu. O tarihten önce ayarlanmış bir değer hiç uygulanmadığı için
yükseltme ikisini de temizler ve önceki değerleri olay günlüğüne kaydeder — ilk kez gözetimsiz
uygulanmaları, aksi halde her çağırana 403 döndürebilirdi. İkisini de bilinçli olarak yeniden
girin.
Denetim uç noktası kendisini çağıran vekili ya da ağ geçidini reddediyor
Şunları görebilirsiniz: Client certificate required (istemci sertifikası gerekli) · API key required (API anahtarı gerekli) · Invalid API key (geçersiz API anahtarı) · Internal API only (yalnızca dahili API)
Başlamadan önce
Denetimler
- 1
Bu dağıtımın istemci sertifikasını zorunlu kılıp kılmadığını okuyun
beklenen · Ya hiçbir DN istenmiyor ya da çağıran bununla eşleşen bir sertifika sunuyor.
- 2
Çağıranın bir ağ geçidi API anahtarı sunup sunmadığını okuyun
beklenen · Çağıran `Bearer cid_key_…` gönderiyor ve anahtar çözümleniyor.
- 3
Çağrının bir ters vekil üzerinden gelip gelmediğini denetleyin
beklenen · Ya çağıran bir anahtar sunuyor ya da dinleyiciye dahili bir adresten doğrudan ulaşıyor.
- 4
Kaynak adrese dayalı herhangi bir denetime güvenmeden önce, çağıranın gerçekte hangi adresle geldiğini denetleyin
beklenen · Çağıranlar kendi adresleriyle geliyor.
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | mtls-required-not-presented (kritik) | mTLS zorunluluğu ek bir kısıttır ve ilk olarak değerlendirilir. 2026-08-29'a kadar yazılıyor, görüntüleniyor ve hiçbir şey tarafından okunmuyordu; o tarihten önce ayarlanmış bir değer hiçbir zaman uygulanmadığı için yükseltme bu alanı temizler ve önceki değeri olay günlüğüne kaydeder. Yükseltmeden sonra yeniden girilen bir değer ise gerçekten zorunlu kılınır. Düzeltme: Konu DN'i yapılandırılmış değerle eşleşen bir istemci sertifikası sunun; bu dağıtımda mTLS çalışmıyorsa DN alanını boşaltın. Yeni bir değer girmeden önce, yükseltmenin temizlediği değeri olay günlüğünden yeniden okuyun. Doğrulama: beklenen · İstek kabul ediliyor. |
| denetim 2 başarısız olduğunda | key-missing-or-unresolvable (kritik) | Hiçbir şeye çözümlenmeyen bir anahtar için "kiracı yok" dönmek, anahtarsız bir çağrıdan ayırt edilemezdi; bu durumda çağıranlar gövdede adı geçen kiracıya geri düşer ve bir anahtar sahibi kayıtları istediği kiracıya atfedebilirdi. Bu nedenle anahtar reddedilir. Düzeltme: Çağıran için bir ağ geçidi API anahtarı düzenleyin ve taşıyıcı jeton olarak yapılandırın. Anahtar varken de reddediliyorsa Ağ geçidi API anahtarı reddediliyor yolunu izleyin. Doğrulama: beklenen · İstek kabul ediliyor ve oluşan kayıtlar beklenen kiracıyı taşıyor. |
| denetim 3 başarısız olduğunda | keyless-through-edge (uyarı) | Bir ters vekilin arkasında her çağıran dahili görünür; dolayısıyla özel ağ ayrıcalığı bütün interneti kabul ederdi. Dinleyici, bir kenar vekilinden gelen anahtarsız çağrıları reddeder ve bunu açıkça söyler. Düzeltme: Çağırana bir ağ geçidi API anahtarı verin ya da dinleyiciye doğrudan ulaşmasını sağlayın. Doğrulama: beklenen · İstek kabul ediliyor. |
| denetim 4 başarısız olduğunda | source-ip-is-the-bridge (uyarı) | CID222'nin yanında sanal makine olarak çalışan bir güvenli web ağ geçidi, dinleyiciye docker köprü adresiyle gelir; çünkü kaynak ağın kendi NAT'ı adresi maskeler. Böyle bir durumda kaynak adres izin listesi ya her çağıranı kabul eder ya hiçbirini, ve iki durumda da hiçbir şey kanıtlamaz. Fiziksel bir yerel ağda adres korunur ve izin listesi çalışır. Düzeltme: Her ICAP çağıranı aynı docker köprü adresiyle geliyor yolunu izleyin. Doğrulama: beklenen · Çağıran kendi adresiyle geliyor. Bu geçerli değilse: Destek paketini ve dinleyicinin ret günlüğü satırlarını ekleyin — bu satırlar görünen kaynak adresini ve gerekçeyi verir. |
Kaynak adresleri göründükleri gibi değil
Laboratuvarda ölçüldü: CID222'nin yanındaki iki SWG sanal makinesi de dinleyiciye aynı docker köprü adresiyle ulaştı. Nedeni kaynak ağın kendi NAT'ıdır; CID de Docker'ın kullanıcı alanı vekili de değil. Fiziksel bir LAN'da adres korunur ve izin listesi çalışır — bu, aynı ana makinedeki sanal makine laboratuvarlarına özgü bir durumdur.
Dinleyici bu durumu tespit eder ve bir kez günlüğe yazar. Herhangi bir kaynak IP denetimine güvenmeden önce o günlüğü okuyun.
Her ICAP çağıranı aynı docker köprü adresiyle geliyor
Şunları görebilirsiniz: her SWG 172.19.0.1 olarak görünüyor · ICAP kaynak IP izin listesi vekillerimizi birbirinden ayırmıyor · allowed_source_ips değerinin hiçbir etkisi yok · izin listesini ayarladıktan sonra her çağıran engellendi
Başlamadan önce
Denetimler
- 1
ICAP dinleyicisinin çağıranları nasıl kabul ettiğini okuyun
tanılama · posture.inspectionSourceIpMode = "unrestricted"
- 2
Çağıranların kendi adresleriyle mi, kapsayıcı köprü adresiyle mi geldiğini denetleyin
beklenen · Kaydedilen kaynak adres, ağ geçidinin kendi adresi.
- 3
Açık bir izin listesi ayarlıysa, kabul edilmesi gereken her çağıranı listelediğini doğrulayın
beklenen · Her çağıran listede.
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 2 başarısız olduğunda | nat-rewrites-the-source (uyarı) | CID222'nin yanında sanal makine olarak çalışan bir ağ geçidi dinleyiciye kendi adresiyle ulaşmaz. Hedef o alt ağın dışına çıkar çıkmaz sanal makine ağının kendi NAT (MASQUERADE) kuralı kaynağı yeniden yazar; laboratuvarda hem bir multipass hem bir libvirt misafiri aynı kapsayıcı köprü adresiyle gelirken ölçüldü. Bu, aynı ana makinedeki laboratuvarlara özgü bir durumdur: fiziksel bir LAN'daki ağ geçidi adresini korur ve denetim çalışır. Düzeltme: Aynı ana makinedeki bir sanal makine laboratuvarında kaynak IP izin listesine güvenmeyin — çağıranları birbirinden ayıramaz ve ayarladığınızda ya hepsini kabul eder ya hiçbirini. O ortamda bir izin listesini sınamak için MASQUERADE kuralının önüne, kapsayıcı alt ağının trafiğini döndüren bir kural ekleyin. Üretimde ağ geçidini cihazın ana makinesine değil ağa yerleştirin. Doğrulama: beklenen · Adres, kapsayıcı köprü adresi değil ağ geçidinin kendi adresi. |
| denetim 1 başarısız olduğunda | unrestricted-admission (uyarı) | Dinleyici eşini kimlik doğrulayamaz — tümleştiği hiçbir ürün bir kimlik bilgisi ya da özel başlık sunmaz — bu yüzden kabul yalnızca adrese dayanır ve kabul edilen bir eşe, her istekte iddia ettiği kullanıcı kimliğine kadar inanılır. Kısıtsız kabul, porta erişebilen her şeyin herhangi bir kullanıcıyı iddia edebilmesi demektir. Düzeltme: Dinleyiciyi, kendisini meşru biçimde çağıran ağ geçitlerinin adresleriyle sınırlayın ve portu yalnızca o ağ geçitlerinin erişebileceği bir segmente koyun. Asıl denetim olarak izin listesini değil ağ yerleşimini görün. Doğrulama: tanılama · posture.inspectionSourceIpMode = "unrestricted" |
| denetim 3 başarısız olduğunda | allowlist-replaced-the-default (kritik) | Açık bir izin listesi, özel aralık varsayılanını genişletmez; onun yerine geçer. Tek bir adres ayarlamak bu nedenle, bir an önce çalışanlar dahil diğer her çağıranın kabulünü kaldırır ve arıza, dinleyicide bir yapılandırma değişikliği olarak değil ağ geçidinde bir ret olarak görünür. Düzeltme: Yalnızca eklemekte olduğunuzu değil, kabul edilmesi gereken her çağıranı listeleyin, sonra her ağ geçidini yeniden sınayın. Bu denetim uygulanmaya başlamadan önce yazılmış değerler yükseltme sırasında temizlendi ve olay günlüğüne kaydedildi; dolayısıyla ayarladığınızı hatırladığınız bir değer artık yerinde olmayabilir. Doğrulama: beklenen · Hepsi kabul ediliyor. |
Vekil sunucunun kendisi
Vekil CA erişilebilir değil
İleri yönlü vekil sunucu isteğe bağlıdır ve CA'sı kendi durumunda saklanır. Kapsayıcıyı yeni bir birimle yeniden oluşturmak yeni bir CA üretir ve eskisine güvenen her istemciye yenisinin verilmesi gerekir — eski güven devredilmez.
İçerik
Parçalı yüklemeler denetlenmez, reddedilir
Hiçbir yol istekler arasında arabelleğe almadığı için parçalı ya da sürdürülebilir bir yükleme
denetlenemez. 2026-08-29'dan bu yana üç yolun üçü de bunları geçirmek yerine varsayılan olarak
reddeder (ICAP ve ileri yönlü vekilde CID_RESUMABLE_UPLOAD_POLICY; eklenti kendi kapalı
kalarak başarısızlık ayarına uyar ve görünür bir "not inspected" olayı kaydeder).
Yeniden birleştirme — yükleme kimliğine göre arabelleğe alma, sonlandırmada denetleme, yeniden parçalama — uygulanmadı; bu yüzden büyük bir dosya gönderen kullanıcı maskeleme değil ret alır. Bu bir arıza değil, kapalı kalarak başarısızlık tercihinin çalışmasıdır.
Bir dosya reddediliyor ya da analizi başarısız oluyor
Şunları görebilirsiniz: No file uploaded (hiçbir dosya yüklenmedi — "file" adlı multipart alanı bekleniyordu) · Image size exceeds maximum allowed size of 10MB (görüntü, izin verilen 10 MB üst sınırını aşıyor) · Unsupported file type (desteklenmeyen dosya türü; PDF, DOCX ya da TXT yükleyin) · legacy and macro-enabled spreadsheet formats cannot be safely redacted (eski ve makro etkin hesap tablosu biçimleri güvenli biçimde maskelenemez)
Başlamadan önce
Denetimler
- 1
Biçimin ürünün kabul ettiği biçimlerden olup olmadığını okuyun
beklenen · Biçim, o yüzeyde kabul ediliyor.
- 2
O yüzeyin boyut sınırını okuyun
beklenen · Dosya, iletide adı geçen sınırın altında.
- 3
İstemcinin parçalı ya da sürdürülebilir bir yükleme yapıp yapmadığını denetleyin
tanılama · posture.resumableUploadPolicy = "block"
- 4
Belge analizinin bu dağıtımda açık olup olmadığını okuyun
beklenen · Servis etkin.
- 5
Belge ayrıştırıcısının kendi sağlığını okuyun
tanılama · services[document-parser].healthy = true
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | format-not-accepted (bilgi) | Bazı biçimler kısmen işlenmek yerine bilinçli olarak reddedilir. Makro etkin bir hesap tablosu güvenli biçimde maskelenemez ve içeriği sessizce atlayan bir maskeleme, retten daha kötü olurdu. Düzeltme: Dosyayı kabul edilen bir biçimde kaydedip yeniden yükleyin — hesap tablosunu makrosuz .xlsx olarak, belgeyi PDF, DOCX ya da TXT olarak.Doğrulama: beklenen · Kabul ediliyor. |
| denetim 2 başarısız olduğunda | over-size-limit (bilgi) | Her yüzey arabelleğe alacağı miktarı sınırlar; çünkü analiz dosyanın tamamını bellekte tutar ve sınırsız bir yükleme, en büyük tespit servisi hangisiyse onun bellek tükenmesi nedeniyle sonlandırılması demektir. Düzeltme: Dosyayı bölün ya da sıkıştırın; büyük taramalarda görüntü yolu yerine belge yolunu kullanın. Doğrulama: beklenen · Kabul ediliyor. |
| buraya yönlendiren denetim yok | resumable-refused-by-policy (uyarı) | Hiçbir yol istekler arasında arabelleğe almadığı için parçalı ya da sürdürülebilir bir yükleme denetlenemez. Üç yolun üçü de bunları denetlenmemiş biçimde geçirmek yerine varsayılan olarak reddeder ve eklenti görünür bir "not inspected" olayı kaydeder. Yeniden birleştirme — yükleme kimliğine göre arabelleğe alma, sonlandırmada denetleme, yeniden parçalama — uygulanmadı. Düzeltme: Kullanıcıdan dosyayı tek bir istekte yüklemesini isteyin ya da politikayı değiştirerek riski açıkça üstlenin. Buradaki bir reddi ürün arızası olarak okumayın: kapalı kalarak başarısızlık tercihinin çalışmasıdır. Doğrulama: tanılama · posture.resumableUploadPolicy = "block" |
| denetim 4 başarısız olduğunda | parser-disabled (uyarı) | Belge analizi ayrı bir servistir ve örneğin asgari bir geliştirme yığınında kapatılabilir. Etkin olup çökmüş bir servisle karıştırılmasın diye uç nokta, ayırt edici bir iletiyle 503 döndürür. Düzeltme: Belge ayrıştırıcısını etkinleştirin ve ayarı yeniden okuması için ağ geçidini yeniden başlatın. Bkz. Bir dosyayı maskeleyin. Doğrulama: beklenen · Analiz çalışıyor. |
| denetim 5 başarısız olduğunda | parser-unhealthy (kritik) | Ağ geçidi, ayrıştırıcının önünde bir devre kesici tutar: ayrıştırıcı art arda başarısız olduğunda ağ geçidi onu çağırmayı bırakır ve anında "geçici olarak erişilemiyor" yanıtı verir; arızanın anlık görünmesinin nedeni budur. Düzeltme: Bir servise erişilemiyor ya da servis kendini sağlıksız bildiriyor yolunu izleyin. Doğrulama: tanılama · services[document-parser].healthy = true Bu geçerli değilse: Destek paketini, dosyanın türünü ve boyutunu ekleyin. Politika belgenin ortamdan çıkmasına izin vermiyorsa belgenin kendisini eklemeyin. |
İlgili
- Satır içi vekil — ileri yönlü vekil sunucunun dağıtımı.
- ICAP tümleşmeleri — sağlayıcıya özgü SWG yapılandırması.
- Tarayıcı Denetimi — bu denetimlerin geldiği politika.
- Erişim anahtarları — çağıranın sunduğu bearer anahtarının verilmesi.
Son güncelleme