کارپوریٹ 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 اور وراثتی پراکسی اور ایپ کا ڈیفالٹ مل کر ایک ساتھ تین ممکنہ وجوہات دیتے ہیں۔

ہر ٹیسٹ میں ایک متغیر رکھیں اور استعمال شدہ منزل ہوسٹ نوٹ کریں۔ اس بنیادی خط کے بغیر اگلا شخص چاروں مراحل شروع سے دہراتا ہے۔