শুধু ওয়েব নেটওয়ার্কে VPN ব্লকড? স্তর ধরে ধরে কাজ করুন

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

কোন স্তর সংযোগ প্রত্যাখ্যান করছে তা প্রমাণ করুন

VPN ক্লায়েন্ট দিয়ে শুরু করবেন না। একই হোস্টে সাধারণ HTTPS অনুরোধ দিয়ে শুরু করুন এবং সময়ের ধাপগুলো পড়ুন, কারণ যে ধাপটি ব্যর্থ হয় সেটিই বলে দেয় কোন ডিভাইস দায়ী:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

এখন আপনি আসলে যে সার্টিফিকেট পান তা দেখুন। সার্ভারের সঙ্গে কথা বলছেন কি না, নাকি সেশন পুনরায় স্বাক্ষরকারী কোনো মধ্যবর্তী বাক্সের সঙ্গে, তা জানার দ্রুততম উপায় এটি:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

প্রক্সি-সচেতন ক্লায়েন্ট প্রথম প্যাকেট বদলায়, নীতি নয়

নেটওয়ার্ক যদি প্রমাণিত প্রক্সির মাধ্যমে CONNECT দাবি করে, তাহলে VPN ক্লায়েন্টকে তা জানাতে হবে, নইলে সে এমন ঠিকানায় সকেট খুলতে চাইবে যা সে রাউট করতে পারে না। প্রক্সি আলাদাভাবে ক্লায়েন্ট থেকে পরীক্ষা করুন, যাতে ব্যর্থতার একটাই ব্যাখ্যা থাকে:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

প্রথম কমান্ড প্রমাণ করে প্রক্সি গন্তব্যটি বহন করবে। দ্বিতীয়টি ক্লায়েন্টকে 443-এ TCP ব্যবহার করতে বলে, যা বেশিরভাগ শুধু-ওয়েব পথ আদৌ এগিয়ে দেয় একমাত্র এই পরিবহন। প্রথম কমান্ড সফল হয়ে দ্বিতীয়টি এখনও ব্যর্থ হলে প্রক্সি বাধা নয়।

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

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

পোর্ট 443 পৌঁছনো যায়, অনুমোদিত নয়

443-এ TLS দিয়ে টানেল মোড়ানো পৌঁছনোযোগ্যতার সমাধান করে, আর কিছু নয়। পোর্ট যাচাইকারী ফিল্টার এটি পার করতে দেবে; হ্যান্ডশেকের ফিঙ্গারপ্রিন্ট নেওয়া ফিল্টার দেবে না, আর এনক্রিপ্টেড ক্লায়েন্ট হ্যালো কেবল তখনই সার্ভার নাম লুকায় যখন দুই প্রান্তই তা সমর্থন করে। পরীক্ষাটি চালান এবং আশা না করে জানুন আপনি কোন ধরনের ফিল্টারের পিছনে।

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

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

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

গতকাল কাজ করা পিয়ারের পাশে খালি হ্যান্ডশেক টাইমস্ট্যাম্পই UDP-এর উত্তর। দুটি DNS প্রশ্ন অন্য প্রশ্নের উত্তর দেয়: স্থানীয় রিজলভার ও একটি পাবলিক রিজলভার এন্ডপয়েন্ট ঠিকানা নিয়ে একমত না হলে আপনাকে স্টিয়ার করা হচ্ছে এবং পরিবহনের যুক্তিটিই ভুল।

মেশিন থেকে আসলে কী বেরিয়েছে যাচাই করুন

ক্লায়েন্ট লগ বলে ক্লায়েন্ট কী বিশ্বাস করে। ক্যাপচার বলে নেটওয়ার্ক কী দেখেছে, আর এই দুইয়ের পার্থক্যেই বেশিরভাগ ঘটনা সমাধান হয়:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

সকেট তালিকা আরও সূক্ষ্ম ঘটনা ধরে: ডিফল্ট রুট আগেই ধরে রাখা দ্বিতীয় টানেল। রাউটিং টেবিল নিয়ে লড়া দুটি ক্লায়েন্ট মাঝে মাঝে এমন ব্যর্থতা তৈরি করে যা হুবহু ব্লকড নেটওয়ার্কের মতো দেখায়, আর ক্যাপচার এমন ইন্টারফেস দিয়ে বেরোনো ট্রাফিক দেখাবে যা আপনি আশা করেননি।

রোলব্যাক, এবং যে নোটটি রাখা উচিত

পরিবর্তনগুলো যেভাবে করেছিলেন তার উল্টো ক্রমে ফিরিয়ে নিন। প্রক্সি ভেরিয়েবল মুছুন, হাতে চালানো ক্লায়েন্ট বন্ধ করুন, এবং যোগ করা যেকোনো রুট বা রিজলভার ওভাররাইড সরান:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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