ওয়েবসাইটগুলি 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 যাচাই করে এবং এখনও রিপোজিটরির স্বাক্ষর পরীক্ষা করে, কারণ ট্রাফিক পরীক্ষা করা প্রক্সি এগুলোর কোনওটি বন্ধ করার কারণ নয়। এটিও যাচাই করুন যে অপ্রমাণিত ক্লায়েন্ট নীরব সময়-শেষের বদলে স্পষ্ট প্রত্যাখ্যান পায়।

চালু টুকরো ও ব্যর্থ আউটপুট একসাথে পরিবর্তন রেকর্ডে রাখুন। পরেরবার একই আটকে থাকার সম্মুখীন ব্যক্তি দুই লাইনের পার্থক্য যেকোনও ব্যাখ্যার চেয়ে দ্রুত চিনবে।