Redsocks শুধু লুপব্যাকে শোনে, কিন্তু VPN ট্রাফিক কখনই পৌঁছায় না

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

রিডাইরেক্ট করা প্যাকেট আসলে কোথায় পড়ে

গেটওয়েতে ট্রান্সপারেন্ট প্রক্সিং PREROUTING-এ nat টেবিলের REDIRECT ব্যবহার করে আগত সংযোগের গন্তব্যকে স্থানীয় পোর্টে পুনর্লিখন করে। পুনর্লিখিত গন্তব্য হল প্যাকেট যে ইন্টারফেসে এসেছে সেখান থেকে দেখা স্থানীয় ঠিকানা, অন্য কোথাও শুরু হওয়া প্রক্রিয়ার লুপব্যাক ঠিকানা নয়। শুধু 127.0.0.1-এ বাঁধা লিসেনার এমন সংযোগ গ্রহণ করে যা ইতিমধ্যে হোস্টে স্থানীয় ছিল, আর টানেল ট্রাফিক ব্যর্থ হওয়ার সময় কাজ চালিয়ে যাওয়া ঘটনা ঠিক এটাই। ক্লায়েন্টের নিজের লুপব্যাক তৃতীয় ঠিকানা এবং কখনও গেটওয়ের নিয়মের লক্ষ্য নয়।

তাই আপস্ট্রিম ক্রেডেনশিয়াল ছোঁয়ার আগে দুটি তথ্য প্রতিষ্ঠা করুন: নিয়মটি কোন স্থানীয় ঠিকানায় পুনর্লিখন করে, আর প্রক্সি সকেট কোন ঠিকানায় বাঁধা।

লিসেনার আর রিডাইরেক্ট নিয়ম একসাথে পড়ুন

সকেট টেবিল আর nat নিয়ম একই পাসে ছাপুন, কারণ যে নিয়ম এমন পোর্টের দিকে দেখায় যার মালিক কেউ নেই, সেটি ভুল ঠিকানার দিকে দেখানো নিয়মের মতোই দেখায়। sudo ss -ltnp | grep redsocks বাইন্ড ঠিকানা আর মালিক প্রক্রিয়া দেখায়। sudo iptables -t nat -S PREROUTING REDIRECT লক্ষ্য দেখায়, আর sudo iptables -t nat -L PREROUTING -v -n দেখায় কিছু এর সাথে মিলেছিল কি না।

REDSOCKS নামের একটি ব্যবহারকারী চেইনে লাফ দেওয়া কিছুই করে না যদি সেই চেইনটি বিদ্যমান না থাকে এবং অভীষ্ট বর্জন ও REDIRECT ক্রিয়া বহন না করে। নামটাই কাজটা করে ধরে নেওয়ার বদলে sudo iptables -t nat -S REDSOCKS দিয়ে যে চেইনে লাফ হয় সেটি পড়ুন।

তারপর দুটি মান তুলনা করুন। যদি নিয়মটি 12345 পোর্টের গেটওয়ে ঠিকানায় রিডাইরেক্ট করে আর লিসেনার 127.0.0.1:12345 জানায়, তবে অমিলটি আর কোনো রোগনির্ণয় ছাড়াই ব্যর্থতার ব্যাখ্যা দেয়।

সংকীর্ণভাবে বাঁধুন, তারপর কী এটি পর্যন্ত পৌঁছাতে পারে তা সীমিত করুন

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

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

ক্লায়েন্ট থেকে নতুন সংযোগ দিয়ে এটি প্রমাণ করুন

গেটওয়ের শেলে নয়, আসল VPN ক্লায়েন্ট থেকে নতুন TCP সংযোগ দিয়ে পরীক্ষা করুন। ক্লায়েন্টে curl -sS -o /dev/null -w '%{http_code}\n' http://example.com রিডাইরেক্ট করা পথটি শুরু থেকে শেষ পর্যন্ত চালায়।

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

সবশেষে মনে রাখুন এই পথ কী ঢাকে না। সাধারণ redsocks TCP রিডাইরেক্ট UDP, QUIC বা DNS-কে SOCKS ট্রাফিকে পরিণত করে না, আর প্রাইভেট গন্তব্যের সাধারণত স্পষ্ট বর্জন দরকার। সফল স্থানীয় পরীক্ষা কেবল সেই লুপব্যাক পথটি প্রমাণ করে যা কখনও সমস্যা ছিল না।