OpenVPN-এর জন্য SOCKS5 প্রক্সি: TCP টানেল নাকি অ্যাপগুলো প্রক্সি করা?

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

একটি সীমাবদ্ধতাই ডিজাইন নির্ধারণ করে

SOCKS5 সত্যিই একটি UDP অ্যাসোসিয়েশন মোড নির্দিষ্ট করে। OpenVPN-এর ক্লায়েন্ট প্রক্সি সমর্থন তবুও স্ট্রিমের চারপাশে গড়া: socks-proxy TCP প্রোফাইলের জন্য নথিভুক্ত, এবং একটি HTTP CONNECT প্রক্সির ডেটাগ্রামের কোনো পথই নেই। ডকুমেন্টেশনের এক লাইনই কনফিগারেশন ফাইল স্পর্শ করার আগে আর্কিটেকচার ঠিক করে দেয়।

তাই প্রশ্নটি কোন প্রক্সি বাছবেন তা নয়। প্রশ্নটি হলো টানেলটি একটি স্ট্রিম হয়ে ওঠে, নাকি ডেটাগ্রাম থাকে এবং অন্য কিছু প্রক্সিং নিজের করে নেয়।

বিকল্প এ: টানেলকে স্ট্রিমে পরিণত করুন

এর জন্য TCP লিসেনারসহ একটি সার্ভার এবং প্রক্সির নাম লেখা একটি ক্লায়েন্ট প্রোফাইল দরকার। দুটি অংশই আবশ্যক, আর সার্ভারের দিকটিই মানুষ ভুলে যায়:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

শেষ লাইনটি http-proxy proxy.internal 8080 দিয়ে বদলান যখন প্রক্সি HTTP বলে, এবং প্রয়োজন হলে একটি ক্রেডেনশিয়াল ফাইল যোগ করুন। প্রক্সিকে অবশ্যই আপনার VPN পোর্টে CONNECT করতে রাজি হতে হবে, আর সার্ভারকে TCP-তে উত্তর দিতে হবে; কেবল UDP লিসেনার সেই চেষ্টা উপেক্ষা করে। 443 বেছে নেওয়া একটি ব্যবহারিক পদক্ষেপ, কারণ অনেক নিষিদ্ধ নেটওয়ার্ক এটি এবং সামান্য অন্য কিছু অনুমোদন করে।

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

বিকল্প বি: টানেলকে একা থাকতে দিন

যখন টানেলকে UDP-তে থাকতেই হবে, তখন টানেল সেই জায়গা নয় যেখানে আপনি কিছু কনফিগার করেন। বরং অ্যাপ্লিকেশন থেকে বাইরের TCP একটি স্থানীয় SOCKS লিসেনারে রিডাইরেক্ট হয়, আর অ্যাপগুলো কখনো জানে না যে একটি প্রক্সি আছে। লিনাক্সে এটি সাধারণত redsocks এবং nat টেবিলে একটি NAT REDIRECT নিয়ম যুক্ত হয়।

আবারও কেবল TCP। privoxy-এর মতো কেবল-HTTP প্রক্সি ইচ্ছামতো প্রোটোকল রিলে করতে পারে না, আর এই ডিজাইন অ্যাপগুলোর জন্য কোনো ডেটাগ্রাম সমর্থনও যোগ করে না।

সফটওয়্যার যেখানে সমর্থন করে সেখানে প্রতিটি অ্যাপকে সরাসরি প্রক্সির কথা বলা সাধারণত ভালো। এটি নিরীক্ষা করা সহজ, এবং এটি এমন জায়গায় ব্যর্থ হয় যা আপনি সত্যিই দেখতে পান।

প্রতিটি বিকল্প কোথায় ব্যর্থ হয়

বিকল্প এ ব্যর্থ হয় যখন সার্ভারে TCP লিসেনার নেই, যখন প্রক্সি CONNECT লক্ষ্য প্রত্যাখ্যান করে, বা যখন বাইরের স্ট্রিম টানেলের প্রয়োজনের নিচে থ্রটল হয়। প্রথম দুটি প্রক্সি লগে একটি এন্ট্রি রেখে যায়; তৃতীয়টি একটি সংযোগ রেখে যায় যা প্রতিষ্ঠিত হয় এবং তারপর ভুল লাগে। প্রোফাইল সম্পাদনার আগে সেই লগ পড়ুন, কারণ এটি অনুমতি সমস্যা থেকে ক্ষমতা সমস্যা আলাদা করে। সম্পন্ন CONNECT তদন্তকে টানেলের ভেতরে নিয়ে যায়।

বিকল্প বি ডেটাগ্রাম প্রয়োজন এমন সবকিছুর জন্য, প্রক্সি যে প্রোটোকল বোঝে না সেগুলোর জন্য, এবং চুপচাপ সেই হোস্টগুলোতে ব্যর্থ হয় যেখানে রিডাইরেক্ট নিয়ম আছে কিন্তু রাউটিং ট্রাফিককে তার পাশ দিয়ে পাঠায়।

কোনো বিকল্পই ডিভাইসের প্রয়োজনীয়তা বদলায় না। কার্নেল রুট করার আগে প্যাকেটের এখনও TUN বা TAP নোড দরকার, তাই প্রক্রিয়াটির এখনও /dev/net/tun-এ অনুমতি দরকার। একটি মোড়ক সেই নোড খোলার পরে কী হয় তা বদলায়, আপনার এটি দরকার কি না তা নয়।

আপনি কোন পথ বানিয়েছেন তা প্রমাণ করা

ট্রে আইকনের বদলে সকেটের দিকে তাকান। VPN প্রক্রিয়াটি প্রক্সি ঠিকানার সঙ্গে একটি প্রতিষ্ঠিত সংযোগ ধরে রাখা উচিত, আর প্রক্সির উচিত যে লক্ষ্যে পৌঁছাতে বলা হয়েছিল তা লগ করা:

ss -tnp | grep openvpn

তারপর এমন একটি গন্তব্যের দিকে যান যা কেবল টানেল পরিবেশন করতে পারে, এবং এমন একটি নামের দিকে যান যার উত্তর কেবল টানেল রিজলভার দিতে পারে। মৃত টানেলের সঙ্গে সম্পন্ন প্রক্সি সংযোগ সাধারণত বোঝায় যে দূরপ্রান্ত আপনার প্রোফাইলে নামকৃত পরিবহন কখনো প্রস্তাব করেনি।

পরিবহন ও গ্রহণকারী প্রক্সি টেকসই কোনো জায়গায় নোট করুন। একই প্রোফাইল অন্য নেটওয়ার্কে ব্যর্থ হলে সেই নোট কয়েক সেকেন্ডে প্রক্সিকে বাদ দেয় বা নিশ্চিত করে।