آپ کے VPN گیٹ وے کو اب بھی اپ ڈیٹس انسٹال کرنے کا راستہ درکار ہے

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

گیٹ وے کو مقفل کرنا درست ہے۔ اسے اتنی سختی سے مقفل کرنا کہ وہ پیچ وصول کرنا بند کر دے ایک الگ فیصلہ ہے، اور عام طور پر حادثاتی۔

مقامی آؤٹ پٹ کلائنٹ فارورڈنگ نہیں ہے

فارورڈنگ کے قواعد ان پیکٹوں پر لاگو ہوتے ہیں جو کہیں اور سے آتے ہیں اور گیٹ وے سے گزر کر نکلتے ہیں۔ گیٹ وے کی اپنی اپ ڈیٹ ٹریفک ان سے کبھی نہیں ملتی؛ یہ مقامی طور پر پیدا ہوتی ہے اور آؤٹ پٹ راستے سے گزرتی ہے۔ یہی فرق ایسی خرابی کی وضاحت کرتا ہے جو ناممکن لگتی ہے جبکہ کلائنٹ رسائی بے عیب کام کرتی ہے۔

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

اس مرحلے کا نام لیں جو ناکام ہوا

اپ ڈیٹ کی غلطیاں مختلف حدود کے نام لیتی ہیں، اور یہ پڑھنے سے پہلے کہ کون سی ناکام ہوئی پورٹ قاعدے کی طرف لپکنا ایک دوپہر ضائع کرتا ہے۔ ایسا ذخیرہ نام جو حل نہ ہو resolver کا سوال ہے، نقل و حمل کا سوال نہیں۔

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

کامیاب تلاش کے بعد ٹائم آؤٹ سوال کو نقل و حمل کی طرف لے جاتا ہے: پیکج مینیجر نے واقعی کون سا پتہ، کون سی پورٹ اور کون سا ترتیب شدہ پراکسی آزمایا۔ TLS تصدیق کی ناکامی تیسرا، بالکل الگ معاملہ ہے، اور اس کا مطلب ہے کہ کنکشن بات چیت کے لیے کافی حد تک کام کر گیا۔ آرکائیو کی توثیق کی شکایت چوتھا مرحلہ ہے، اور یہ دستخط شدہ میٹا ڈیٹا سے متعلق ہے نہ کہ رسائی سے۔ چار مراحل، چار مختلف مرمت، اور ping ہمیشہ صرف ایک پروٹوکول بیان کرتا ہے جو کوئی پیکج مینیجر استعمال نہیں کرتا۔

قاعدہ شامل کرنے سے پہلے ذرائع کی فہرست پڑھیں

ذرائع کے اصل URI اور مؤثر پراکسی ترتیب کی فہرست بنائیں، وہ نہیں جو آپ کو یاد ہیں۔ سادہ HTTP کے لیے لکھا گیا قاعدہ بے کار ہے جب ذریعہ HTTPS ہو، اور شیل کا جانا ہوا پراکسی ایسی سروس کے لیے نظر نہ آ سکے جو بوٹ کے وقت مختلف ماحول کے ساتھ شروع ہو۔

APT کی HTTP ٹرانسپورٹ دستاویزات ماحولیاتی اور APT کے مخصوص پراکسی ترتیبات کا احاطہ کرتی ہیں، بشمول ہر میزبان کے لیے انتخاب، اور اس کے HTTPS ٹرانسپورٹ کی اپنی تصدیقی ترتیبات ہیں۔ براؤزر کا راستہ اور پیکج مینیجر کا راستہ الگ الگ راستے ہیں، یہاں تک کہ ایک ہی مشین پر۔

غور کریں کہ ذرائع کن پتہ خاندانوں میں حل ہوتے ہیں۔ صرف IPv4 کی اجازت دینے والا قاعدہ ایسے میزبان پر ناکام ہوتا رہے گا جس کے ذرائع AAAA ریکارڈ کو ترجیح دیتے ہیں، اور غلطی وقفے وقفے سے لگتی ہے کیونکہ یہ اس پر منحصر ہے کہ کون سا جواب پہلے آتا ہے۔

دیکھ بھال کا ایک راستہ چنیں اور اس پر قائم رہیں

تین قابل دفاع اختیارات ہیں: دیکھ بھال کی ٹریفک سرنگ کے ذریعے، منظم اپ ڈیٹ پراکسی کے ذریعے، یا تنگ براہ راست استثنا کے ذریعے۔ کسی ایک کو جان بوجھ کر چنیں اور resolver کو اس سے متفق کریں، کیونکہ ایسی تقسیم جس میں نام ایک سمت حل ہوں اور کنکشن دوسری سمت جائیں ایسی ناکامیاں پیدا کرتی ہے جنہیں کوئی نہیں سمجھا سکتا۔

آپ جو بھی چنیں، یہ غیر محدود متبادل نہیں بننا چاہیے۔ اگر سرنگ بند ہونے پر براہ راست آؤٹ باؤنڈ ٹریفک ممنوع ہو، تو دیکھ بھال کا ایسا استثنا جو خاموشی سے سب کچھ اجازت دے، اصلاح کے لباس میں تبدیلیٔ پالیسی ہے۔ سرنگ کا اپنا اینڈ پوائنٹ اور bootstrap کی ضروریات کو ذخیرے تک رسائی سے الگ زمرے میں رکھیں، کیونکہ وہ مختلف منازل کی طرف اشارہ کرتے ہیں اور مختلف طریقوں سے ناکام ہوتے ہیں، لہٰذا ایک استثنا دوسرے کو ڈھانپ نہیں سکتا۔

جانچ کمزور کیے بغیر تصدیق کریں

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

کامیاب نقل و حمل تصدیق کو نرم کرنے کی اجازت نہیں۔ آرکائیو کی توثیق اور TLS سرور کی شناخت الگ الگ ضمانتیں ہیں، اور کسی ایک کو کسی غلطی کو خاموش کرنے کے لیے بند کرنا اس چیز کو بدلتا ہے جس پر آپ بھروسہ کرتے ہیں، نہ کہ اس چیز کو جس تک آپ پہنچ سکتے ہیں۔

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