Uygulama istekleri kurumsal VPN arkasında başarısız oluyor ama tarayıcı çalışıyor

Tarayıcı siteyi yüklerken bir uygulama kırılıyor. Devraldığı proxy'yi, port ilkesini, ham TCP sıfırlamalarını ve yük boyutu sınırlarını bu sırayla inceleyin.

İç portalı tarayıcıda açıyorsunuz ve yükleniyor. Aynı ana bilgisayarı çağıran uygulamayı çalıştırıyorsunuz ve başarısız oluyor; mesaj hiçbir katmanı adlandırmıyor. Tünel tarayıcıyı taşıyor, dolayısıyla tünel ilk şüpheli değil. İsteğiniz ile hizmet arasında dört şey var ve her biri farklı bir iz bırakıyor. Benim izlediğim sıra şu: VPN istemcisinin ayar sayfasından değil, uygulamanın gerçekten gönderdiği istekten başlıyorum.

Uygulamanın gerçekten gönderdiği isteğe bakın

Yapılandırmaya dokunmadan önce uygulamaya ne yaptığını söyletin. Proxy açıkça kapatılmış hâlde tek istek yakalamak ve basit bir port testi, sonraki adımların karşılaştırılacağı iki temel çizgi verir. İstek proxy kapalıyken başarılıysa dört katmanın üçünü bitirmişsinizdir.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Son ikisini aynı hedefe çalıştırın ve nerede ayrıştıklarına bakın. Çalışan bir tarayıcı artı çalışan bir curl artı çalışmayan bir uygulama, sorunu uygulamanın eklediği bir şeye daraltır: bir proxy, bir taşıma veya bir mesaj boyutu.

Uygulama kimsenin yapılandırmadığı bir proxy'yi devraldı

Çoğu HTTP yığını proxy yapılandırmasını varsayılan olarak işletim sisteminden okur. Kurumsal VPN istemcisi bunu genellikle erişim profilinin parçası olarak kurar, bu yüzden istekler geliştiricinin kodda hiç anmadığı bir proxy'den çıkar. .NET'te varsayılan işleyici IE/WinHTTP ayarlarından okur; Java -Dhttp.proxyHost okur; Node'da bir kitaplık ekleyene kadar yerleşik proxy desteği yoktur. Hata nadiren temiz bir reddetmedir, bu yüzden insanlar sunucuya bakmaya başlar.

Testin maliyeti tek istek: proxy'yi tek bir işleyicide açıkça kapatın ve karşılaştırın.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Bu işe yararsa düzeltme tünele değil, uygulamanın yapılandırmasına aittir. Projedeki her çalışma zamanı için denetimi yineleyin, çünkü her biri farklı bir kaynak okur ve yalnızca biri bozuk olabilir.

Seçtiğiniz port, ilkenin izin verdiği port değil

Yönlendirilmiş bir ana bilgisayar, izin verilmiş bir hizmet değildir. Kurumsal ilke genellikle giden web portlarına izin verip gerisini düşürür, bu yüzden 8080 veya 1883 üzerindeki bir hizmet erişilemezken 443 sorunsuz çalışır. Tarayıcı burada hiçbir şey kanıtlamaz: tanım gereği 443 kullanır.

Aynı hizmeti 443 arkasında yayınlayın ve istisna istemeden önce adıyla ona ulaşın. İstisna gerçekten gerekliyse, onu tek bir kaynak aralığına ve tek bir hedefe sınırlayın ve birinin kişisel kestirmesi değil, hizmet tanımının parçası olarak ele alın.

Yolun sıfırladığı ham TCP

Uzun ömürlü ham TCP bağlantıları en kafa karıştırıcı biçimde başarısız olan katmandır. Web trafiğine izin veren bir yol yine de olağandışı giden TCP'yi sıfırlayabilir veya yeniden yazabilir ve istemci kesinti gibi okunan bir soket hatası bildirir. Mesajlaşma ve olay hizmetleri genellikle tam bu tür ağlar için WebSocket taşıması sunar ve geçiş, tünel değişikliği değil istemci seçeneğidir.

Taşımayı değiştirin, yeniden test edin ve aynı çalıştırmada başka hiçbir şeyi değiştirmeyin. Bu tek değişkenli test, sıfırlamanın yoldan mı yoksa hizmetten mi geldiğini söyler.

Yalnızca büyük yüklerde kapanan bağlantılar

Başarılı olup yaklaşık bir saniye sonra ölen, ama yalnızca gövde büyükken ölen bir istek, ortada bir yerdeki boyut sınırına işaret eder. Mesaj baytlarını sayan bir aracı, bağlantıyı aktarımın ortasında düşürebilir ve istemci zaman aşımı yerine anormal kapanma bildirir.

Yükü uygulama katmanında parçalara bölün. Bunu MTU işinden ayrı tutun: tünelin paket boyutunu düşürmek, sıradan TCP oturumları sabit bir bayt sayısında takıldığında yardımcı olur ve bir aracının çok büyük saydığı mesaj için hiçbir şey yapmaz.

Dördünü tek geçişte nasıl ayırt edersiniz

Üç gözlem çoğu durumu çözer. Hata hemen mi oluyor, yoksa yalnızca büyük gövdeyle mi? Proxy kapalıyken aynı istek başarılı oluyor mu? Portu veya taşımayı değiştirdiğinizde sonuç değişiyor mu? Yanıtları bir sonraki değişiklikten önce yazın, çünkü kurumsal VPN artı devralınan proxy artı uygulama varsayılanı size aynı anda üç olası neden verir.

Her testte tek değişken tutun ve kullandığınız hedef ana bilgisayarı not edin. O temel çizgi olmadan bir sonraki kişi dört adımı da baştan yineler.

İlgili makaleler