د اپلیکیشن غوښتنې د شرکت VPN تر شا ناکامېږي، خو براوزر کار کوي

تاسو په براوزر کې داخلي پورټل پرانیزئ او بارېږي. هغه اپلیکیشن چلوئ چې هماغه هوسټ غواړي او ناکامېږي، د داسې پیغام سره چې هېڅ طبقې ته نوم نه اخلي. تونل براوزر وړي، نو تونل لومړنی شکمن نه دی. ستاسو د غوښتنې او خدمت ترمنځ څلور شیان دي، او هر یو بېل نښه پرېږدي. دا هغه ترتیب دی چې زه یې تعقیبوم، له هغې غوښتنې څخه پیل چې اپلیکیشن واقعاً لېږي، نه د VPN کلاینټ د تنظیماتو پاڼې څخه.

هغه غوښتنه وګورئ چې اپلیکیشن واقعاً لېږي

له ترتیب سره د لاس وهلو مخکې، اپلیکیشن ته ووایاست چې څه کوي. د یوې غوښتنې نیول چې پراکسي په ښکاره ډول بند وي او یوه ساده د پورټ ازموینه تاسو ته دوه بنسټیزې کرښې درکوي چې راتلونکي ګامونه ورسره پرتله کیږي. که غوښتنه د پراکسي د بندیدو سره بریالۍ شي، له څلورو طبقو درې یې بشپړې کړې دي.

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

وروستي دوه دې ورته هدف ته وچلوئ او وګورئ چې چېرته جلا کیږي. کار کوونکی براوزر او کار کوونکی curl او نه کار کوونکی اپلیکیشن ستونزه هغه څه ته محدوده کوي چې اپلیکیشن ورزیاتوي: پراکسي، ترانسپورت یا د پیغام اندازه.

اپلیکیشن هغه پراکسي په میراث کې ترلاسه کړ چې چا تنظیم نه و کړی

ډېری HTTP سټکونه په ډیفالټ ډول د عملیاتي سیسټم څخه د پراکسي ترتیبات لولي. شرکت VPN کلاینټ اکثراً یو د خپل لاسرسي پروفایل په برخه کې نصبوي، نو غوښتنې هغه پراکسي ته ورځي چې جوړونکي په کوډ کې هېڅکله یاد نه کړ. په .NET کې ډیفالټ هینډلر له IE/WinHTTP تنظیماتو څخه اخلي؛ Java -Dhttp.proxyHost لولي؛ Node د کتابتون تر اضافه کېدو پورې کورنی پراکسي ملاتړ نه لري. ناکامي کمزورې پاکه انکار وي، له همدې امله خلک سرور ته ګوري پیل کوي.

ازموینه یوه غوښتنه لګښت لري: پراکسي په یو هینډلر کې په ښکاره ډول بند کړئ او پرتله یې کړئ.

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

که دا بریالۍ شي، اصلاح د اپلیکیشن په ترتیباتو کې ده، نه په تونل کې. د پروژې هر رنټایم لپاره ازموینه تکرار کړئ، ځکه هر یو بېل سرچینه لولي او یوازې یو یې خراب وي.

هغه پورټ چې تاسو غوره کړی هغه نه دی چې تګلاره یې اجازه ورکوي

د لارې لرونکی هوسټ اجازه ورکړل شوی خدمت نه دی. شرکت تګلاره معمولاً وتونکي ویب پورټونه اجازه ورکوي او پاتې نور غورځوي، نو په 8080 یا 1883 کې خدمت نه رسیږي خو 443 ښه کار کوي. براوزر دلته هېڅ ثابتوي نه: هغه د تعریف له مخې 443 کاروي.

هماغه خدمت د 443 تر شا خپور کړئ او د استثنا غوښتلو مخکې په نوم ورته ورسئ. که استثنا واقعاً اړینه وي، یوې سرچینې حد او یو هدف ته یې محدوده کړئ او د خدمت د تعریف برخه یې وګڼئ، نه د چا شخصي لاره.

خام TCP چې لاره یې بیا تنظیموي

اوږد ژوند لرونکي خام TCP اړیکې هغه طبقه ده چې تر ټولو ګډوډ کوونکې ناکامېږي. هغه لاره چې د ویب ټرافیک اجازه ورکوي بیا هم کولای شي غیر معمولي وتونکی TCP بیا تنظیم یا بیا ولیکي، او کلاینټ د سوکیټ تېروتنه راپور کوي چې د قطعې په څېر لوستل کیږي. د پیغامونو او پیښو خدمتونه معمولاً د همدې ډول شبکې لپاره WebSocket ترانسپورت وړاندې کوي، او بدلول د کلاینټ انتخاب دی، نه د تونل بدلون.

ترانسپورت بدل کړئ، بیا ازموینه وکړئ او په هماغه چلند کې بل څه مه بدل کړئ. هغه یو-متغیره ازموینه وایي چې بیا تنظیم له لارې راغی که له خدمت څخه.

هغه اړیکې چې یوازې د لویو بارونو په وخت بندېږي

هغه غوښتنه چې بریالۍ کیږي او بیا نږدې یوه ثانیه وروسته مري، خو یوازې هغه وخت چې بدن لوی وي، په مینځ کې یوې اندازې حد ته اشاره کوي. هغه منځګړی چې د پیغامونو بایټان شمېري کولای شي اړیکه د لېږد په مینځ کې وغورځوي، او کلاینټ د وخت د پای ته رسېدو پرځای غیر نورمال بندېدل راپور کوي.

بار په اپلیکیشن طبقې کې ټوټې کړئ. دا له MTU کار څخه جلا وساتئ: د تونل د پاکټ اندازې کمول هغه وخت مرسته کوي چې عادي TCP ناستې په ثابته بایټ شمېره ودریږي، او هغه پیغام لپاره چې منځګړی یې خورا لوی ګڼي هېڅ نه کوي.

څنګه څلور واړه په یوه پاس کې جلا کړو

درې مشاهدې ډېری قضیې حل کوي. آیا ناکامي سمدلاسه پیښیږي که یوازې د لوی بدن سره؟ آیا هماغه غوښتنه د پراکسي بندیدو سره بریالۍ کیږي؟ آیا نتیجه بدلیږي چې پورټ یا ترانسپورت بدل کړئ؟ ځوابونه د بل بدلون مخکې ولیکئ، ځکه شرکت VPN او میراثي پراکسي او د اپلیکیشن ډیفالټ یوځای درې احتمالي لاملونه درکوي.

په هرې ازموینه کې یو متغیر وساتئ او هغه هدف هوسټ ولیکئ چې کارولی مو دی. پرته له دې بنسټیزې کرښې بل کس څلور واړه ګامونه له سره تکراروي.