Ilova so‘rovlari korporativ VPN ortida muvaffaqiyatsiz bo‘ladi, brauzer esa ishlaydi
Brauzer saytni yuklayotganda bitta ilova buziladi. Meros qolgan proksi, port siyosati, xom TCP qayta sozlashlari va yuk hajmi cheklovlarini shu tartibda ko‘rib chiqing.
Ichki portalni brauzerda ochasiz va u yuklanadi. Xuddi shu hostni chaqiradigan ilovani ishga tushirasiz va u muvaffaqiyatsiz bo‘ladi, hech bir qatlamni nomlamaydigan xabar bilan. Tunnel brauzerni tashimoqda, shuning uchun tunnel birinchi gumondor emas. So‘rovingiz va xizmat o‘rtasida to‘rtta narsa bor va har biri boshqa iz qoldiradi. Men amal qiladigan tartib shu: VPN mijozi sozlamalar sahifasidan emas, ilova haqiqatan yuboradigan so‘rovdan boshlanadi.
Ilova haqiqatan yuboradigan so‘rovni ko‘ring
Konfiguratsiyaga tegishdan oldin ilovaga nima qilishini aytishga ruxsat bering. Proksini aniq o‘chirib bitta so‘rovni tutish va oddiy port sinovi sizga keyingi qadamlar taqqoslanadigan ikkita tayanch chiziq beradi. Proksi o‘chirilganda so‘rov o‘tsa, to‘rtta qatlamdan uchtasi allaqachon tugagan.
env | grep -i proxy # Linux/macOS
netsh winhttp show proxy # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080Oxirgi ikkitasini bir xil manzilga ishga tushiring va qayerda ajralishini kuzating. Ishlaydigan brauzer va ishlaydigan curl va ishlamaydigan ilova muammoni ilova qo‘shadigan narsaga toraytiradi: proksi, transport yoki xabar hajmi.
Ilova hech kim sozlamagan proksini meros oldi
Ko‘pchilik HTTP steklari proksi konfiguratsiyasini sukut bo‘yicha operatsion tizimdan o‘qiydi. Korporativ VPN mijozi ko‘pincha uni o‘z kirish profili tarkibida o‘rnatadi, shuning uchun so‘rovlar dasturchi kodda hech qachon eslatmagan proksidan chiqadi. .NET da standart ishlovchi IE/WinHTTP sozlamalaridan oladi; Java -Dhttp.proxyHost ni o‘qiydi; Node da kutubxona qo‘shmaguncha ichki proksi qo‘llab-quvvatlanmaydi. Muvaffaqiyatsizlik kamdan-kam toza rad etish bo‘ladi, shuning uchun odamlar serverga qaray boshlaydi.
Sinov bitta so‘rovga tushadi: proksini bitta ishlovchida aniq o‘chiring va taqqoslang.
var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);Agar bu o‘tsa, tuzatish tunnelga emas, ilova konfiguratsiyasiga tegishli. Loyihadagi har bir ish muhiti uchun auditni takrorlang, chunki har biri boshqa manbani o‘qiydi va faqat bittasi buzilgan bo‘lishi mumkin.
Siz tanlagan port siyosat ruxsat beradigan port emas
Marshrutlangan host ruxsat etilgan xizmat emas. Korporativ siyosat odatda chiquvchi veb-portlarga ruxsat berib, qolganini tashlaydi, shuning uchun 8080 yoki 1883 dagi xizmat yetib bo‘lmaydigan bo‘ladi, 443 esa yaxshi ishlaydi. Brauzer bu yerda hech narsani isbotlamaydi: u ta’rif bo‘yicha 443 dan foydalanadi.
Xuddi shu xizmatni 443 ortida e’lon qiling va istisno so‘rashdan oldin unga nom bilan yeting. Agar istisno haqiqatan kerak bo‘lsa, uni bitta manba oralig‘i va bitta manzil bilan cheklang va uni birovning shaxsiy chetlanishi emas, xizmat ta’rifining qismi deb qarang.
Yo‘l qayta sozlaydigan xom TCP
Uzoq umr ko‘radigan xom TCP ulanishlari eng chalkash tarzda muvaffaqiyatsiz bo‘ladigan qatlam. Veb-trafikka ruxsat beradigan yo‘l ham g‘ayrioddiy chiquvchi TCP ni qayta sozlashi yoki qayta yozishi mumkin, mijoz esa uzilish kabi o‘qiladigan soket xatosini xabar qiladi. Xabar va hodisa xizmatlari aynan shunday tarmoq uchun WebSocket transportini taqdim etadi, almashtirish esa tunnel o‘zgarishi emas, mijoz tanlovi.
Transportni almashtiring, qayta sinab ko‘ring va o‘sha ishga tushirishda boshqa hech narsani o‘zgartirmang. O‘sha bitta o‘zgaruvchili sinov qayta sozlash yo‘ldan keldimi yoki xizmatdan — shuni aytadi.
Faqat katta yuklarda yopiladigan ulanishlar
Muvaffaqiyatli bo‘lib, keyin taxminan bir soniyadan so‘ng o‘ladigan, lekin tana katta bo‘lgandagina o‘ladigan so‘rov o‘rtada biror joydagi hajm chegarasiga ishora qiladi. Xabarlar baytlarini sanaydigan vositachi ulanishni uzatish o‘rtasida tashlab yuborishi mumkin, mijoz esa vaqt tugashi o‘rniga g‘ayrioddiy yopilishni xabar qiladi.
Yukni ilova qatlamida bo‘laklarga bo‘ling. Buni MTU ishidan alohida tuting: tunnel paketi hajmini pasaytirish oddiy TCP sessiyalari doimiy bayt sonda to‘xtab qolganda yordam beradi va vositachi juda katta deb hisoblaydigan xabar uchun hech narsa qilmaydi.
To‘rttasini bir o‘tishda qanday ajratish mumkin
Uch kuzatuv holatlarning ko‘pini hal qiladi. Muvaffaqiyatsizlik darhol bo‘ladimi yoki faqat katta tana bilanmi? Proksi o‘chirilganda o‘sha so‘rov o‘tadimi? Port yoki transportni almashtirganda natija o‘zgaradimi? Javoblarni keyingi o‘zgarishdan oldin yozib qo‘ying, chunki korporativ VPN va meros proksi va ilova sukut qiymati bir vaqtda uchta ehtimoliy sabab beradi.
Har bir sinovda bitta o‘zgaruvchi tuting va ishlatgan manzil hostini yozib boring. O‘sha tayanch chiziqsiz keyingi odam to‘rtta qadamni ham boshidan takrorlaydi.