ব্রাউজার Squid-এর মাধ্যমে একটি HTTP পেজ লোড করে। একই গন্তব্য proxychains-এর অধীনে ব্যর্থ হয়। এর অর্থ এই নয় যে দুটি প্রোগ্রামের একটি ভুল প্রক্সি IP বেছে নিয়েছে।

সাধারণ HTTP-সচেতন ক্লায়েন্ট ওয়েব অনুরোধটি HTTP প্রক্সি রূপে ফরওয়ার্ড প্রক্সিতে পাঠাতে পারে। কিন্তু একটি সাধারণ সকেট মোড়ককে বাইট টানেল দরকার, যে সংযোগটি অ্যাপ্লিকেশন খুলতে চেয়েছিল। নিজের চেইনে থাকা HTTP প্রক্সির জন্য proxychains CONNECT ব্যবহার করে।

এর অর্থ এই যে পোর্ট 80-এ থাকা একটি প্লেইনটেক্সট ওয়েবসাইট পোর্ট 80-এর জন্য CONNECT অনুরোধ তৈরি করতে পারে। কেবল অনুমোদিত TLS পোর্ট তালিকায় CONNECT অনুমোদনকারী Squid নীতি সেই টানেল প্রত্যাখ্যান করতে পারে, যদিও পোর্ট 80-এ সাধারণ HTTP অনুরোধ অনুমোদিত।

কেবল হোস্টনেম নয়, অনুরোধ তুলনা করুন

proxychains-ng-এর নথি তার HTTP CONNECT সমর্থন বর্ণনা করে। Squid-এর অ্যাক্সেস নিয়ম পদ্ধতি ও গন্তব্য পোর্ট আলাদা করতে পারে। এগুলি একই ওয়েবসাইটে যাওয়ার ভিন্ন ভিন্ন অনুরোধ পথ।

পরিবর্তনের আগে প্রত্যাখ্যান ও অভীষ্ট নীতি পড়ুন। CONNECT অ্যাক্সেস সব পোর্টে বাড়ানো একটি বড় পরিবর্তন; মোড়কের অসঙ্গতির জন্য এটি ডিফল্ট সমাধান হওয়া উচিত নয়।

অ্যাপ্লিকেশনের নিজস্ব HTTP প্রক্সি সমর্থন থাকলে, তা ব্যবহার করলে প্লেইনটেক্সট HTTP-এর জন্য অপ্রয়োজনীয় সাধারণ টানেল এড়ানো যায়। সত্যিই কাঁচা TCP টানেল দরকার হলে, এমন অনুমোদিত প্রক্সি প্রোটোকল ও পোর্ট নীতি বেছে নিন যা তা সরবরাহ করে।

সফল ব্রাউজার অনুরোধ প্রক্সির নাগাল ও একটি সমর্থিত অনুরোধ পদ্ধতি সম্পর্কে উপযোগী প্রমাণ। কিন্তু এটি প্রমাণ করে না যে প্রতিটি টানেল পদ্ধতি, গন্তব্য পোর্ট বা অ্যাপ্লিকেশন প্রোটোকল সেই প্রক্সির মাধ্যমে অনুমোদিত।

সম্পর্কিত নিবন্ধ