Squid SO_ORIGINAL_DST ত্রুটি পড়া

NF getsockopt(SO_ORIGINAL_DST) মূল গন্তব্যের সন্ধানের দিকে ইঙ্গিত করে। ইন্টারসেপশন ব্যবস্থায় Squid-কে পুনর্নির্দেশিত সংযোগটি আদতে কোথায় যাচ্ছিল তা পুনরুদ্ধার করতে হয়।

স্পষ্টভাবে কনফিগার করা ব্রাউজার ইচ্ছাকৃতভাবেই অনুরোধ প্রক্সিতে পাঠায়। শুধু Squid লিসেনারের পোর্টের পাশে intercept লেখা থাকার কারণে সেই সংযোগ NAT ইন্টারসেপশনের ইতিহাস পায় না।

তাই এই অমিল গন্তব্যের সার্টিফিকেট প্রাসঙ্গিক হওয়ার আগেই ব্যর্থ হতে পারে।

সংযোগটি কীভাবে এল তা দিয়ে শুরু করুন

• অ্যাপ্লিকেশনে প্রক্সি ঠিকানা কনফিগার করা থাকলে, তার ব্যবহারযোগ্য সাধারণ ফরোয়ার্ড-প্রক্সি লিসেনার নির্ধারণ করুন।
• গেটওয়ে অন্যথায় সরাসরি ট্রাফিক পুনর্নির্দেশ করলে, তা নির্ধারিত ইন্টারসেপশন লিসেনারে পৌঁছায় কি না এবং সমর্থিত NAT নকশা প্রয়োজনীয় গন্তব্য তথ্য সংরক্ষণ করে কি না দেখুন।
• দুটি মোডই থাকলে, ব্যর্থ ক্লায়েন্টটি আসলে কোন ঠিকানা ও পোর্টে সংযোগ করেছিল তা দেখুন।

Squid-এর http_port নথি পার্থক্যটি স্পষ্ট করে: মোড ফ্ল্যাগ বাদ দিলে ফরোয়ার্ড-প্রক্সি মোড বাছা হয়; intercept IP স্তরে NAT ইন্টারসেপশন আশা করে।

এরপর পরিবহন নিরাপত্তা আলাদাভাবে দেখুন। একটি HTTP প্রক্সি CONNECT দিয়ে HTTPS বহন করতে পারে। প্রক্সিতে TLS সংযোগের জন্য উপযুক্ত লিসেনার ও ক্লায়েন্ট কনফিগারেশন দরকার। গন্তব্য ট্রাফিক ডিক্রিপ্ট করা আরেকটি ঐচ্ছিক সক্ষমতা।

গন্তব্য URL HTTPS দিয়ে শুরু বলে সার্টিফিকেট তৈরি চালু করা পুরনো “HTTPS সমাধান” নকল করবেন না। আগে ক্লায়েন্ট ও লিসেনারের মধ্যে সমন্বয় ঠিক করুন। এরপর প্রকৃত TLS ত্রুটি থাকলে তা তদন্তের জন্য বেশি কাজে দেবে।