APT র্যাপার ছাড়াই SOCKS5h ব্যবহার করতে পারে
যেসব APT সংস্করণে SOCKS5h সমর্থন নথিভুক্ত, সেখানে প্রক্সি URI HTTP বা HTTPS পরিবহন সেটিংসের অধীনে থাকে, কোনো উদ্ভাবিত Acquire::socks বিভাগে নয়।
“APT through SOCKS” নিয়ে পুরোনো উত্তরগুলো প্রায়ই র্যাপার বা HTTP-to-SOCKS রিলে সুপারিশ করে। সেই উত্তরগুলো পুরোনো সংস্করণের প্রকৃত সীমাবদ্ধতা বর্ণনা করতে পারে। তবে socks5h সমর্থন নথিভুক্ত এমন APT সংস্করণে সেগুলোই একমাত্র বিকল্প নয়।
একটি কনফিগারেশন অংশ বিদ্যমান acquisition transport কী ব্যবহার করতে পারে:
Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";এই উদাহরণ ধরে নেয় যে একই মেশিনে একটি অনুমোদিত SOCKS5 লিসেনার ইতিমধ্যে আছে। এটি একটি চালু করে না। SSH ডাইনামিক ফরোয়ার্ড সেই স্থানীয় লিসেনার তৈরির একটি উপায়। প্রক্সিটি দূরবর্তী হলে বরং তার প্রকৃত পৌঁছানোযোগ্য এন্ডপয়েন্ট ব্যবহার করুন; SOCKS5 প্রক্সি তালিকার প্রার্থীরা কেবল সেখানেই প্রযোজ্য যেখানে রিপোজিটরি অনুরোধের জন্য পাবলিক প্রক্সি অনুমোদিত।
স্কিমটি নির্দেশনার অংশ
APT ট্রান্সপোর্ট ম্যানুয়াল দূরবর্তী DNS রিজলিউশনসহ SOCKS5-এর জন্য socks5h তালিকাভুক্ত করে। ইনস্টল করা সংস্করণের জন্য নথিভুক্ত স্কিমটি ব্যবহার করুন, অন্য কোনো প্রোগ্রাম কাকতালীয়ভাবে গ্রহণ করে এমন লেবেলে সংক্ষিপ্ত করবেন না।
একইভাবে, পুরোনো ফোরাম স্নিপেটে Acquire::socks::Proxy থাকা এই প্রমাণ নয় যে HTTP acquisition পদ্ধতি সেই সেটিং পড়ে। একটি কনফিগারেশন পার্সার কী গ্রহণ করতে পারে, যদিও কোনো ডাউনলোড পদ্ধতি তা ব্যবহার না করে।
স্থানীয় ঠিকানার একটি সীমা আছে
APT যখন কনটেইনার বা ভার্চুয়াল মেশিনের ভিতরে চলে, 127.0.0.1 সেই পরিবেশকে বোঝায়। হোস্টে থাকা SOCKS লিসেনার একটি ভিন্ন এন্ডপয়েন্ট। স্থানীয় সংযোগ প্রত্যাখ্যাত হওয়ার কারণ নির্ণয়ের আগে APT কোথায় চলছে তা যাচাই করুন।
SOCKS সমর্থন রিপোজিটরি স্বাক্ষর বা HTTPS সার্টিফিকেট যাচাইও সরায় না। সেই সুরক্ষাগুলো চালু রাখুন। ইনস্টল করা APT-তে নথিভুক্ত সামর্থ্য না থাকলে, অচেনা URI স্কিমকে পাসওয়ার্ড সমস্যা হিসেবে না দেখে অনুমোদিত বিকল্প বা আপডেট পথ বেছে নিন।