Tinyproxy-এ Listen, Bind আর BindSame: কোন ঠিকানাটি জেতে

Listen সেই ঠিকানাটি বেছে নেয় যা ক্লায়েন্ট গ্রহণ করে, Bind বহির্গামী সংযোগের উৎস বেছে নেয়। কোনোটিই রুট বসায় না, তাই পথটি আলাদাভাবে যাচাই করুন।

প্রক্সি উত্তর দেয়, অনুরোধ শেষ হয়, তবুও গন্তব্যটি এখনও ল্যান ঠিকানাটিই লিখে রাখে. প্রক্সি লগে কিছুই ভুল দেখায় না, আর আপনি যে লাইনটি বদলেছেন সেটিই ডকুমেন্টেশন বলেছিল বদলাতে। যে হোস্টে ল্যান ঠিকানা ও টানেল ঠিকানা দুটোই আছে, সেখানে কোন ঠিকানা কোথায় দেখাবে তা ঠিক করে তিনটি নির্দেশ, এবং তাদের মধ্যে কেবল একটি বহির্গামী দিক নিয়ে। ভুল ক্রমে পড়লে কারণ ছাড়াই আপনি রাউটিং টেবিলে ঢুকে পড়বেন।

উপসর্গ: গন্তব্য ল্যান ঠিকানাটি দেখছে

একটি ক্লায়েন্ট ল্যান ঠিকানায় প্রক্সির সঙ্গে যুক্ত হয়, আর প্রক্সি গন্তব্যের দিকে নিজের সংযোগ খোলে। সেই দ্বিতীয় সংযোগটি কার্নেলের নিয়মে উৎস ঠিকানা বেছে নেয়, এবং ডিফল্টে সেটিই হয় যা রুট অনুসন্ধান বেছে দেয়। তাই প্রতিটি বাইট প্রক্সির মধ্য দিয়ে গেলেও গন্তব্য হোস্টের প্রাথমিক ঠিকানাটিই লিখে রাখে। ফরওয়ার্ডিংয়ের অর্থে কিছুই ভাঙা নেই, তাই প্রক্সি লগের এ নিয়ে বলার কিছু থাকে না।

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

তিনটি নির্দেশ, তিনটি আলাদা ঠিকানা

Listen সেই স্থানীয় ঠিকানার নাম দেয় যা প্রক্সি ক্লায়েন্ট গ্রহণ করে। Bind বাইরের দিকে প্রক্সির তৈরি সংযোগের জন্য উৎস ঠিকানা দেয়, আর BindSame তাকে বলে সদ্য গৃহীত সংযোগের স্থানীয় ঠিকানাটিই পুনরায় ব্যবহার করতে। এগুলো তিনটি আলাদা প্রশ্ন, আর একটি লাইন কেবল একটির উত্তর দেয়। এদের গুলিয়ে ফেলাই সাধারণত পরিবর্তনটি কিছুই করছে না বলে মনে হওয়ার কারণ।

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

ইনস্টল করা সংস্করণের সঙ্গে আসা টীকাযুক্ত কনফিগারেশনটি পড়ুন, কারণ ডিফল্ট ও গৃহীত সিনট্যাক্স রিলিজভেদে বদলায়। প্রকল্পের নমুনা কনফিগারেশন প্রতিটি নির্দেশ অন্যগুলোর পাশে নথিভুক্ত করে। ওই ফাইলটি ডিস্কে থাকা ফাইলের সঙ্গে মেলান, অন্য কোনো ডিস্ট্রিবিউশনের জন্য লেখা গাইডের সঙ্গে নয়।

শ্রোতা ও বহির্গামী উৎস আলাদাভাবে সেট করুন

এমন একটি হোস্ট নিন যার ল্যান ঠিকানা 192.168.50.10 এবং টানেল ঠিকানা 10.90.0.3। ল্যান ক্লায়েন্টরা যদি প্রক্সিতে পৌঁছায় আর তাদের অনুরোধ টানেল দিয়ে বেরোয়, তবে এ দুটি স্বতন্ত্র সিদ্ধান্ত এবং দুটোই লিখতে হবে। নিচের অংশটি ঠিক তেমনটাই বলে, এর বেশি কিছু নয়।

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

এটি সম্পূর্ণ কনফিগারেশন নয়, তাই অনুমোদিত পোর্ট, প্রমাণীকরণ, ক্লায়েন্ট প্রবেশাধিকার নিয়ন্ত্রণ ও গন্তব্য-সীমাবদ্ধতা রেখে দিন। দুটি ঠিকানাই Tinyproxy-র নেটওয়ার্ক নেমস্পেসের ভিতরে এই হোস্টের হতে হবে, কারণ প্রসেস যে Bind মানের মালিক হতে পারে না তা শুরুতে নয়, সংযোগের সময় ব্যর্থ হয়। BindSame yes অন্য নীতি বোঝায়, যেখানে গৃহীত সংযোগের স্থানীয় ঠিকানাই বহির্গামী উৎস হয়ে যায়। চলতি সংস্করণে ওই শাখা Bind তালিকার চেয়ে অগ্রাধিকার পায়, আর এভাবেই কনফিগার করা উৎস কোনো ত্রুটি ছাড়াই অদৃশ্য হয়।

উৎস যে রুট বোঝায় তা যাচাই করুন

উৎস ঠিকানা বাছাই করলে পথ তৈরি হয় না, তাই কার্নেলকে জিজ্ঞাসা করুন ওই উৎস ও ওই গন্তব্যে সে কী করবে। যে অনুসন্ধান টানেল ইন্টারফেসের নাম বলে তা ন্যূনতম প্রমাণ, আর যে ল্যান ইন্টারফেসের নাম বলে তার মানে উৎসটি লেখা অনুযায়ী কাজ করতে পারবে না। অনুসন্ধানটি প্রসঙ্গভিত্তিক: এটি ওই নেমস্পেসের জন্য কার্যকর নীতি-নিয়ম ও টেবিল মূল্যায়ন করে। এটি কোনো সংযোগ নয়, আর নিম্নধারার NAT পরিষেবার কাছে কী উপস্থাপন করবে সে সম্পর্কে কিছুই বলে না।

ip -4 route get 203.0.113.25 from 10.90.0.3

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

গন্তব্যে উৎস নিশ্চিত করুন

অনুরোধ যেখানে পৌঁছায় সেখানে উৎস পড়ুন, যেখান থেকে বেরোয় সেখানে নয়। গন্তব্যের অ্যাপ্লিকেশন লগ বা তার সামনের এজ ডিভাইস যে ঠিকানা সত্যিই দেখেছে তা লিখে রাখে, আর প্রক্সি আপনাকে কেবল তার ইচ্ছার কথা বলতে পারে। পরিবর্তনের পর উদ্দিষ্ট শ্রোতা দিয়ে একটি নতুন অনুরোধ করুন, কারণ ক্যাশে থাকা সংযোগ নতুন বাইন্ডিং সম্পর্কে কিছুই প্রমাণ করে না। তারপর রেকর্ড করা ঠিকানাটি আপনার কনফিগার করা ঠিকানার সঙ্গে মেলান।

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl কেবল ট্রাফিক তৈরি করে; যাচাইয়ের যোগ্য ঠিকানাটি দূর প্রান্তে লগ হওয়া ঠিকানা, curl যে পিয়ারের সঙ্গে হঠাৎ যুক্ত হয়েছিল সেটি নয়। দুটি না মিললে ঠিক করুন পার্থক্যটি উৎস-নির্বাচন থেকে আসছে না আরও পরে অনুবাদ থেকে, কারণ সেগুলো আলাদা জায়গায় সারানো হয়। ঠিকানা বদল ও প্রক্সি পুনরারম্ভ একসঙ্গে পরিকল্পনা করুন, কারণ টানেল আর যে ঠিকানার মালিক নয় তা বাঁধলে পুনঃসংযোগের পর চুপচাপ ব্যর্থ হয়। DNS ও IPv6-এর আচরণও আলাদাভাবে ঠিক করুন, কারণ উপরের IPv4 অংশটি দুটির কোনোটিই প্রমাণ করে না।

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