کارپوریٹ VPN پر کنٹینر کا HTTPS رک جاتا ہے؟ DTLS ٹانگ جانچیں

کارپوریٹ VPN کے پیچھے موجود کنٹینر کے اندر DNS حل ہوتا ہے، لاگ اِن صفحہ لوڈ ہوتا ہے، صحت کا اینڈ پوائنٹ جواب دیتا ہے، اور پھر HTTPS درخواست وقت ختم ہونے تک رک جاتی ہے۔ امیج دوبارہ بنانا اور پراکسی متغیرات بدلنا کچھ نہیں بدلتا، کیونکہ خراب حصہ امیج میں نہیں ہے۔ کلائنٹ ایک ٹرانسپورٹ پر تصدیق کرتا ہے اور بڑا ڈیٹا دوسرے پر منتقل کرتا ہے، اور صرف دوسرا خراب ہے۔

دو ٹرانسپورٹ، ایک الجھا دینے والی علامت

TLS پر مبنی کارپوریٹ کلائنٹ عام طور پر ایک معمولی TLS کنکشن پر تصدیق کرتا ہے، پھر سیشن کے لیے UDP پر مبنی دوسرا ڈیٹا چینل طے کرتا ہے۔ جب وہ دوسری ٹانگ کام کرتی ہے تو تھرو پٹ اور تاخیر بہتر ہوتی ہے۔ جب اسے فلٹر کیا جائے یا وہ راستے میں نہ سمائے، بڑی منتقلی سے پہلے سب کچھ کامیاب ہوتا ہے اور منتقلی خود رک جاتی ہے، جو بالکل اوپر والا نمونہ ہے۔

کنٹینر وہ گفت و شنید نہیں بدلتا؛ وہ راستہ بدلتا ہے جس سے بیرونی پیکٹ گزرتے ہیں۔ میزبان کنٹینر کے بہاؤ کا ترجمہ کرتا ہے، اس لیے UDP ڈیٹاگرام کلائنٹ کے مقامی ساکٹ سے مختلف ماخذ پورٹ سے نکلتے ہیں اور ایسے ترجمہ اندراج سے واپس آتے ہیں جو قائم شدہ TCP بہاؤ کے مقابلے بہت چھوٹے ٹائمر پر ختم ہوتا ہے۔ اگر ٹنل میزبان پر چلے اور کنٹینر میں ناکام ہو، تو ایپلیکیشن کو قصوروار ٹھہرانے سے پہلے ان دو بہاؤ کا موازنہ کریں۔ یہ موازنہ کسی بھی امیج دوبارہ بنانے سے زیادہ طے کرتا ہے۔

الہام سے نہیں، تجربے سے فیصلہ کریں

سب سے سستا تجربہ UDP ڈیٹا چینل بند کر کے درخواست دہراتا ہے۔ ڈیسک ٹاپ ریپر کے بجائے کمانڈ لائن کلائنٹ استعمال کریں، تاکہ پرچم واقعی لاگو ہو: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. اگر رکی ہوئی درخواست اب مکمل ہو، تو DTLS ٹانگ ہی مسئلہ تھی اور باقی شور تھا۔

اسی کنٹینر سے دونوں سمتوں میں نتیجہ تصدیق کریں: پرچم کے ساتھ ایک بڑی درخواست اور اس کے بغیر ایک۔ پرچم کی پیروی کرنے والا رویہ تبدیلی ثبوت ہے؛ آخر میں لوڈ ہونے والا صفحہ ثبوت نہیں۔

اگر پرچم اسے درست کرے، تو وجہ طے کریں

تین حالتیں ایک ہی علامت پیدا کرتی ہیں، اور مختلف ردعمل مانگتی ہیں۔ راستہ UDP کو مکمل طور پر فلٹر کر سکتا ہے، جو اس نیٹ ورک کے لیے پرچم کو درست مستقل جواب بناتا ہے۔ راستہ UDP کی اجازت دے مگر بڑے ڈیٹاگرام گرا دے، جو فلٹرنگ نہیں بلکہ MTU کی طرف اشارہ کرتا ہے۔ یا راستہ اتنا نقصان زدہ ہو کہ UDP ٹانگ TCP سے بدتر کارکردگی دے، جو صلاحیت کا فیصلہ ہے، رسائی کا نہیں۔

کسی متبادل حل کو دستاویزی بنانے سے پہلے ان میں فرق کریں۔ فلٹرنگ ہر پیکٹ سائز میں قائم رہتی ہے، MTU مسائل صرف ایک حد سے اوپر ظاہر ہوتے ہیں، اور نقصان صاف رکنے کے بجائے دوبارہ ترسیل اور بدلتی تاخیر کی صورت میں ظاہر ہوتا ہے۔ ہر جانچ کلائنٹ ترتیب بدلے بغیر وجہ کو تنگ کرتی ہے۔

متبادل حل رکھنے سے پہلے پیکٹ سائز دیکھیں

اگر وجہ سائز ہے، تو ٹنل انٹرفیس ایسے پیکٹ قبول کرتا ہے جو راستہ اٹھا نہیں سکتا، اور پے لوڈ بڑھتے ہی مسئلہ کسی بھی ٹرانسپورٹ پر واپس آتا ہے۔ انٹرفیس کا موازنہ کریں: میزبان پر ip link show tun0، پھر نیٹ ورک اختیارات میں درج MTU پڑھنے کے لیے docker network inspect bridge۔ کم اٹھانے والی ٹنل کے نیچے اب بھی 1500 بائٹ پر کھڑا کنٹینر برج عام دریافت ہے۔

ٹنل کے اندر تقسیم کی ممانعت کی جانچ کے ساتھ معلوم اچھے سائز سے اوپر تلاش کریں، پھر کنٹینر نیٹ ورک کا MTU کم کریں یا ٹنل پر TCP MSS سکیڑیں۔ دونوں میں سے کوئی بھی اصلاح اکثر UDP راستے کو دوبارہ قابل استعمال بناتی ہے اور پرچم کی ضرورت ہٹا دیتی ہے، جو فلٹرنگ وجہ نہ ہونے پر بہتر نتیجہ ہے۔

طے کریں کہ آپ کیا بدلنے کو تیار ہیں

ڈیٹا چینل بند ہونے پر ٹنل اپنا بوجھ TCP کنکشن کے اندر اٹھاتی ہے۔ صاف راستے پر یہ صرف سست ہے؛ نقصان زدہ پر ایک گم شدہ قطعہ اس کے پیچھے سب کچھ موخر کرتا ہے اور بیرونی دوبارہ ترسیل اندرونی سے مقابلہ کرتی ہے۔ یہ تبادلہ متعامل ترقی اور چھوٹی API کالوں کو راس آتا ہے، اور بڑی منتقلیوں یا موبائل لنک پر طویل سیشنوں کو برا لگتا ہے۔

آپ کوئی بھی اختیار چنیں، درج کریں کہ ٹنل نے آخر میں کون سی ٹرانسپورٹ استعمال کی اور کیوں۔ کسی نے مہینے پہلے جوڑا پرچم خاموشی سے جس پر منحصر کنٹینر ہو وہی اگلا خلل ہے، اور اسے ڈیبگ کرنے والے کو معلوم نہیں ہوگا کہ پرچم فلٹرنگ کے لیے متبادل تھا یا MTU تجربے کا بچا ہوا حصہ۔