ویب سائٹیں VPN کے ذریعے لوڈ ہوتی ہیں، مگر apt مخزن تک نہیں پہنچتا

VPN جڑ جاتا ہے، اندرونی ویکی براؤزر میں لوڈ ہوتی ہے، اور apt update اب بھی ایسے آئینے پر اٹکا رہتا ہے جہاں وہ پہنچ نہیں سکتا۔ اُس تصویر میں سرنگ میں کچھ بھی ٹوٹا نہیں ہے۔ براؤزر اور پیکیج مینیجر نے پراکسی کے دو الگ فیصلے کیے، اور اُن میں سے صرف ایک کنفیگر تھا۔

کون سا فیصلہ ناکام ہوا، یہی پہلے طے کرنے کے لائق واحد بات ہے۔

ترتیب کو چھونے سے پہلے خرابی پڑھیں

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

کچھ بھی بدلنے سے پہلے وہی درست لائن اور وہ مخزن نقل کریں جس کا وہ نام لیتی ہے۔ „وقت ختم ہو گیا“ جیسی دھندلی یاد ہی دس منٹ کی تشخیص کو پوری دوپہر میں بدل دیتی ہے۔

APT اپنی الگ پراکسی ترتیبات رکھتا ہے

APT /etc/apt/apt.conf.d/، مرکزی apt.conf اور APT_CONFIG کے نام کردہ ہر فائل کو پڑھتا ہے۔ یہ ڈیسک ٹاپ پراکسی پروفائل، GNOME نیٹ ورک ترتیب یا براؤزر ایکسٹینشن نہیں پڑھتا۔ ٹرانسپورٹ البتہ پراکسی ماحولی متغیرات کا احترام کرتا ہے، اسی لیے آپ کے شیل میں کام کرنے والا export https_proxy=... کسی دوسرے ماحول میں چلنے والے ٹائمر کے بارے میں کچھ ثابت نہیں کرتا۔

ناکام ہونے والا عمل واقعی کیا دیکھتا ہے، وہ ڈمپ کریں: apt-config dump | grep -i proxy۔

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

پراکسی وہاں مقرر کریں جہاں کنفیگریشن کا مالک اُس کی توقع کرتا ہے

منتظم کے منظور کردہ واضح پراکسی کے لیے نئی فائل میں ایک چھوٹا ٹکڑا کافی ہے:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

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

ٹکڑے کو نئی شمار شدہ فائل کے طور پر شامل کریں، مثلاً /etc/apt/apt.conf.d/95proxy۔ تقسیم کی فائل کے اوپر لکھنے کا مطلب یہ ہے کہ اگلی پیکیج اپ ڈیٹ آپ کی تبدیلی خاموشی سے واپس کر دے گی۔

اسناد URI سے باہر رہتی ہیں

APT ٹرانسپورٹ حوالہ توثیق کے لیے apt_auth.conf کی طرف اشارہ کرتا ہے، اور صارف نام و پاس ورڈ وہیں جاتے ہیں۔ اُنہیں پراکسی URI میں شامل کرنے سے وہ عمل کی فہرستوں، شیل تاریخ اور ٹکٹ میں چپکائے گئے ہر کنفیگریشن ڈمپ میں پہنچ جاتے ہیں۔ توثیق فائل کو سخت اجازتیں چاہیے، کیونکہ وہ اسناد کا ذخیرہ ہے۔

اسکیم بھی جانچیں۔ HTTPS مخزن تک اب بھی HTTP پراکسی کے ذریعے پہنچا جا سکتا ہے؛ ٹرانسپورٹ آئینے کی URI اسکیم سے الگ انتخاب ہے۔

گرافیکل سافٹ ویئر مرکز الگ فرنٹ اینڈ ہے۔ اگر یہ PackageKit یا snap بیک اینڈ استعمال کرتا ہے، تو APT کا ٹکڑا اُس کے لیے کچھ نہیں بدلتا، اس لیے تصدیق کریں کہ ناکام درخواست کس عمل نے کی۔

راستے کی تصدیق کریں، صرف اخراج کوڈ کی نہیں

ٹکڑا لگنے کے بعد سبز نتیجے پر بھروسا کرنے کے بجائے درخواست کو دیکھیں۔ apt-get -o Debug::Acquire::http=true update کنکشن کی کوشش، منتخب پراکسی اور جوابی کوڈ چھاپتا ہے، جو غلط پراکسی کو اُس پراکسی سے الگ کرتا ہے جس نے آپ کو مسترد کیا۔

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

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