OpenVPN এখনো 443-এ আটকে আছে? নেটওয়ার্ক কী যাচাই করে দেখুন

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

হ্যান্ডশেক সংখ্যার চেয়ে বেশি কিছু ফাঁস করে

TCP 443-এ একটি নেটিভ VPN লিসেনার প্রথম প্যাকেট থেকেই নিজের প্রোটোকল বলে। ClientHello-তে থাকে একটি সংস্করণ ক্ষেত্র, একটি এলোমেলো মান ও একটি এক্সটেনশন তালিকা, আর কয়েকশো বাইট পড়া একটি ডিভাইস কিছুই ডিক্রিপ্ট না করেই পার্থক্য বুঝে ফেলতে পারে। পোর্ট নম্বর মেটানো সস্তা, আর ফিল্টার আসলে যা যাচাই করে তা হলো প্রোটোকলের আকার। নিয়ম সাধারণত প্রতি প্রোটোকল ধরেও লেখা হয়, তাই TLS পরিদর্শন করা নীতি UDP সম্পর্কে কিছুই বলে না।

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

স্ট্রিম মোড়কানো দুটি ব্যর্থতার জায়গা তৈরি করে

stunnel-এর মতো একটি TLS মোড়ক প্রত্যাশিত আকার ফিরিয়ে আনে: ক্লায়েন্ট একটি স্থানীয় লিসেনারে সংযোগ করে, মোড়কটি সার্ভারের সঙ্গে 443-এ সত্যিকারের TLS সেশন খোলে, আর সার্ভারের দ্বিতীয় মোড়ক ডিক্রিপ্ট করা বাইটগুলো VPN ডেমনে পাঠায়। বাইরের সেশনটি এখন অন্য যেকোনো HTTPS সংযোগের মতো দেখায়। সার্ভারের VPN ডেমনটির কেবল loopback-এ শোনা উচিত, কারণ মোড়কের বাইরে কিছুই এর কাছে পৌঁছাতে হবে না।

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

মোড়কের পথেই ফাঁদ

টানেল চালু হলে ডিফল্ট রুট তার ভেতরে নির্দেশ করে, আর বাইরের TLS সেশনটির এমন পথ দরকার যা সে যে টানেল বহন করছে তার ভেতরে ঢোকে না। সাধারণ VPN ক্লায়েন্ট যে ঠিকানায় ডায়াল করে তা সুরক্ষা দেয়; মোড়কযুক্ত ক্লায়েন্ট নিজের loopback-এ ডায়াল করে, তাই মোড়কের গন্তব্য ঠিকানা ওই সুরক্ষার কাছে অদৃশ্য।

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

Android-এ ওই ব্যতিক্রমের সমতুল্য হলো প্রতি-অ্যাপ সেটিং: মোড়ক অ্যাপটিকে টানেল থেকে বাদ দিন যাতে তার নিজের ট্রাফিক মোবাইল সংযোগ দিয়ে বেরোয়। বাদ না দিলে মোড়কটি যে টানেল বানাতে চাইছে তার ভেতরেই চলে যায়, আর পুনঃসংযোগের চক্রটি সার্ভারের সমস্যার মতো দেখায়।

কিছু বদলানোর আগে সময়টা পড়ুন

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

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

যা দেখা গেল তা লিখে রাখুন: সেশনটি কতক্ষণ টিকল, সকেট খুলল কি না, মোড়ক হ্যান্ডশেক লগ করল কি না। এর প্রতিটি পরের পরীক্ষাকে সংকুচিত করে।

একবারে একটি চলক পরীক্ষা করুন

আগে UDP দেখুন, কারণ কিছু নেটওয়ার্ক এটি পুরোপুরি ফেলে দেয় আর UDP ব্যর্থতা 443 সম্পর্কে কিছুই বলে না। তারপর মোড়ক ছাড়া TCP 443 চেষ্টা করুন, পরে 443-এ মোড়ক। প্রতিটি ধাপে ক্লায়েন্ট লগ পড়ুন আর আচরণ বদলালেই থামুন।

প্রতিটি চেষ্টায় একটি উপাদান বদলান। নতুন পোর্ট, নতুন মোড়ক আর নতুন সাইফার একই দৌড়ে রাখলে তিনটির কোনটি গুরুত্বপূর্ণ ছিল তা আপনি বলতে পারবেন না।