VPN বনাম প্রক্সি: কোনটি কী ঢাকে আর কী ঢাকে না
VPN রাউট করা অ্যাপ ট্র্যাফিক ঢাকে; প্রক্সি ঢাকে আপনি কনফিগার করা অ্যাপটিকে। বেছে নেওয়ার আগে কভারেজ, এনক্রিপশন, DNS ও ব্যর্থতার আচরণ যাচাই করুন।
VPN এবং ফরোয়ার্ড প্রক্সি—দুটোই একটি ওয়েবসাইট যে ঠিকানা দেখে তা বদলে দেয়, আর বেশিরভাগ তুলনা এখানেই থেমে যায়। আপনার সেটআপ নির্ধারণ করে যে পার্থক্য তা হলো কভারেজ: ফরোয়ার্ড প্রক্সি এমন এক মধ্যস্থ যা আপনার অ্যাপ্লিকেশন নিজে ব্যবহার করার সিদ্ধান্ত নেয়, ওয়েবসাইটের সামনে বসে থাকা রিভার্স প্রক্সির বিপরীতে, আর VPN অপারেটিং সিস্টেম যা টানেলে রাউট করে তা সরিয়ে নেয়। এনক্রিপশন, DNS পরিচালনা ও ব্যর্থতার আচরণ—সবই এই বিভাজন থেকে আসে। এই পাঁচটি যাচাই ক্রমে চালান, আর প্রথমটি ব্যর্থ হলেই বোঝা যাবে আপনার আসলে কোন টুল দরকার।
মধ্যস্থতা কোন অ্যাপগুলো ঢাকে?
ব্রাউজার প্রক্সি এক্সটেনশন কেবল সেই ব্রাউজার প্রোফাইলে কাজ করে। মেইল ক্লায়েন্ট, প্যাকেজ ম্যানেজার ও দ্বিতীয় ব্রাউজার নিজেদের সেটিংস ব্যবহার করতে থাকে, আর কিছু অ্যাপ্লিকেশন সিস্টেম প্রক্সি ভেরিয়েবল পুরোপুরি উপেক্ষা করে। VPN যা ঢাকে তা হলো রাউটিং টেবিল টানেলে যা পাঠায়—রাউট ও ক্লায়েন্ট নীতির উপর নির্ভর করে তা সব অ্যাপ্লিকেশন বা স্প্লিট-টানেলের একটি উপসেট হতে পারে।
একটি পেজ লোড থেকে অনুমান না করে গুরুত্বপূর্ণ অ্যাপ্লিকেশনগুলো পরীক্ষা করুন। curl https://ifconfig.me এনভায়রনমেন্ট প্রক্সি ভেরিয়েবল অনুসরণ করে; ডেস্কটপ অ্যাপ নাও করতে পারে। Windows-এ netsh winhttp show proxy সার্ভিসগুলো যে WinHTTP প্রক্সি ব্যবহার করে তা দেখায়, আর এটি ব্রাউজারের সেটিং থেকে আলাদা।
হপটি এনক্রিপ্টেড কি, আর TLS কোথায় শেষ হয়?
প্রক্সি প্রোটোকল একটি মিলনস্থল, কোনো নিশ্চয়তা নয়। SOCKS5 TCP এনক্রিপ্ট না করেই এগিয়ে পাঠায়, আর সাধারণ HTTP প্রক্সি রিকোয়েস্ট লাইন ও হেডার স্পষ্ট টেক্সটে বহন করে। প্রক্সির মধ্য দিয়ে HTTPS CONNECT ব্যবহার করে, তাই আপনার TLS সেশন প্রক্সিতে নয়, গন্তব্যেই শেষ হয়। প্রক্সি সার্ভার ও টানেলিং নিয়ে MDN-এর নির্দেশিকা প্রোটোকলের দিক থেকেই সেই পার্থক্য ব্যাখ্যা করে।
VPN আপনার ডিভাইস ও তার এন্ডপয়েন্টের মধ্যবর্তী অংশটি এনক্রিপ্ট করে। এন্ডপয়েন্টের পরেও অন্য যেকোনো নেটওয়ার্কের মতোই একই নিয়ম প্রযোজ্য, তাই কেবল একটি টানেল সেই অ্যাপ্লিকেশনকে রক্ষা করে না যা সাধারণ HTTP-তে ক্রেডেনশিয়াল পাঠায়। কোনোটিই লগইন করা অ্যাকাউন্ট, কুকি বা ব্রাউজার ফিঙ্গারপ্রিন্ট লুকায় না।
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullবিস্তারিত আউটপুট দেখায় curl পোর্ট 443-এ CONNECT পাঠিয়েছে কি না, নাকি সম্পূর্ণ URL দিয়ে সাধারণ GET পাঠিয়েছে। socks5h:// দিয়ে হোস্টনেমটি SOCKS5 রিকোয়েস্টের ভেতরে প্রক্সিকে দেওয়া হয়, আর প্রক্সি এমন TLS রিলে করে যা সে পড়তে পারে না—তাই সে নাম ও বাইট সংখ্যা দেখে। http:// প্রক্সির মধ্য দিয়ে https:// URL একটি CONNECT, তাই সেই প্রক্সিও গন্তব্যের নাম ও আয়তন দেখে, রিকোয়েস্ট বা রেসপন্স বডি নয়।
নামটি কোন রিজলভার দেখে?
রিকোয়েস্ট বেরোনোর আগে নাম রিজলিউশন স্থানীয়ভাবেই হতে পারে, অথবা প্রক্সিতে দূর থেকে। curl-এ socks5h:// হোস্টনেম প্রক্সিকে পাঠায়, আর socks5:// প্রথমে তা স্থানীয়ভাবে রিজলভ করে। ব্রাউজার প্রক্সি সেটিংস তুলনীয় DNS বিকল্প দেয়, আর PAC ফাইল বিভিন্ন হোস্টকে বিভিন্ন পথে পাঠাতে পারে।
দুটি প্রোটোকল কোনো ভুল কনফিগারেশন ছাড়াই প্রক্সি এড়িয়ে যেতে পারে। WebRTC STUN-এর মাধ্যমে প্রার্থী সংগ্রহ করে, আর QUIC UDP-এর উপর HTTP/3 চালায়, যা TCP প্রক্সি বহন করতে পারে না। UDP 443 অবরুদ্ধ থাকলে ব্রাউজার TCP-তে ফিরে আসবে, তাই হোস্ট ফায়ারওয়ালে (বা পুরো নেটওয়ার্কের জন্য রাউটারে) UDP 443 অবরুদ্ধ করা—ব্রাউজার ফ্ল্যাগ নয়—HTTP/3-কে প্রক্সি পথের ভেতরে রাখার নির্ভরযোগ্য উপায়।
রিজলভারকে আপনার ল্যাপটপের দিক থেকে নয়, গন্তব্যের দিক থেকে যাচাই করুন। যে রিকোয়েস্ট প্রক্সির এক্সিট ঠিকানা নিয়ে আসে কিন্তু স্থানীয়ভাবে রিজলভ করা নাম বহন করে, তা স্থানীয় রিজলভারকে আপনার দেখা সাইটগুলো জানিয়েই দেয়।
মধ্যস্থতা ব্যর্থ হলে কী হয়?
স্পষ্ট প্রক্সি বন্ধ অবস্থায় ব্যর্থ হয়: প্রক্সি প্রসেস থামালে ব্রাউজার বা অ্যাপ সরাসরি না গিয়ে সংযোগ ত্রুটি দেয়। PAC ও WPAD সেটআপগুলোই খোলা অবস্থায় ব্যর্থ হয়—স্ক্রিপ্ট আনা না গেলে ক্লায়েন্ট DIRECT-এ ফিরে যায় এবং সাইট আবার আপনার আসল ঠিকানা দেখে। VPN ক্লায়েন্ট ও কিল সুইচ বা ফায়ারওয়াল নিয়ম সক্রিয় আছে কি না তার উপর নির্ভর করে খোলা বা বন্ধ অবস্থায় ব্যর্থ হতে পারে।
ব্যর্থতার ঘটনাটি ইচ্ছাকৃতভাবে পরীক্ষা করুন: প্রক্সি সার্ভিস থামিয়ে রিলোড করুন; সরাসরি লোডের বদলে ত্রুটি পৃষ্ঠা পেলে PAC URL-টি একটি অগম্য হোস্টে দেখিয়ে ফলব্যাক দেখুন। পৃষ্ঠাটি যদি আপনার সাধারণ পথেই লোড হয়, তাহলে প্রক্সি নিজের বিভ্রাটের বিরুদ্ধে কোনো সুরক্ষা দেয় না, আর এটি এমন একটি বৈশিষ্ট্য যা তার উপর নির্ভর করার আগে জানা দরকার।
ক্রমই ঠিক করে সাইট কী দেখবে। যে প্রক্সির আউটবাউন্ড VPN-এর মধ্য দিয়ে যায়, সাইট VPN এন্ডপয়েন্টের ঠিকানা দেখে; প্রক্সিকে টানেলের বাইরে রাখলে (দূরবর্তী হোস্টের প্রক্সিতে VPN) সাইট বরং সেই প্রক্সির এক্সিট ঠিকানা দেখে। দুই ক্ষেত্রেই দুটি হপ ভিন্ন ভিন্ন জিনিস লগ করতে পারে।
পাঁচটি যাচাই, ক্রমে
নিচের চেকলিস্টটাই পুরো সিদ্ধান্ত এক জায়গায়। কভারেজ প্রথমে আসে কারণ এটি বেশিরভাগ অমিল দূর করে: যে অ্যাপটি ঢাকতে হবে সেটি সেটিং মানলে না, তালিকার পরে কোনো কিছুই তাকে বাঁচাতে পারবে না।
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
তারপর যে অ্যাপ পরিবর্তনটি ঘটিয়েছে তার দিয়েই ফলাফল নিশ্চিত করুন। কনফিগার করা ব্রাউজারে একটি পৃষ্ঠা লোড করুন, curl দিয়ে একই পৃষ্ঠা আনুন, এবং প্রতিটি যে ঠিকানা জানায় তা তুলনা করুন। তারা মিললে না, এর মানে একটি এক্সটেনশন, PAC নিয়ম বা অ্যাপ-স্তরের ওভাররাইড এখনো কাজ করছে, আর টানেল টিউনিং দিয়ে তা ঠিক হবে না।
আপনি কী কনফিগার করেছেন তা লিখে রাখুন: কোন অ্যাপগুলো প্রক্সি ব্যবহার করে, DNS স্থানীয় না দূরবর্তী, UDP অবরুদ্ধ কি না, এবং ব্যর্থতার আচরণ কী। এই ছোট তালিকাটাই পরবর্তী তুলনা সম্ভব করে, কারণ “IP বদলেছে” কখনোই বলেনি এই পাঁচটি যাচাইয়ের কোনটি পাশ করেছে।