OpenVPN-এর ভেতরে TLS কোথায় বসে, আর কী شکل বদলায়
OpenVPN তার নিয়ন্ত্রণ চ্যানেলের জন্য TLS চালায় নিজের ফ্রেমিংয়ের ভেতরে, তাই প্রথম বাইটগুলো কোনো ওয়েব হ্যান্ডশেক নয়। তিনটি বিকল্প সত্যিই যা দেখা যায় তা বদলায়।
OpenVPN সত্যিই TLS ব্যবহার করে, আর লোকেরা নিয়মিত এটিকে এমন একটি দাবি পর্যন্ত বাড়িয়ে দেয় যা এটি বহন করতে পারে না: যে টানেল তাই সাইটে যাওয়া ব্রাউজারের মতো দেখায়। প্রথম অংশটি সত্য। দ্বিতীয়টি নয়। এখানে TLS নিয়ন্ত্রণ চ্যানেলের, যা OpenVPN-এর নিজের কন্টেইনারের ভেতরে চলে, পাশে সম্পূর্ণ ভিন্ন ক্রিপ্টোগ্রাফির পেলোড চ্যানেল, তাই যে ব্যক্তি শুরুর বাইটগুলো পরীক্ষা করে সে OpenVPN দেখে।
এক খামে দুটি কথোপকথন
একটি সেশনকে একই খাম ভাগ করা দুটি কথোপকথন হিসেবে ভাবুন। একটি সার্টিফিকেট যাচাই করে ও কী উপাদান বের করে। অন্যটি আপনি আসলে যা পাঠাচ্ছেন তা প্রথমটির উৎপন্ন দিয়ে এনক্রিপ্ট করে।
খামটাই প্রোটোকল। প্রতিটি প্যাকেট শুরু হয় একটি ছোট হেডার দিয়ে যা তার ধরন বলে, আর সেই হেডার বাকি সবকিছুর আগে আসে।
আসলে সবার আগে কী আসে
সেই ক্রমের কারণে তারে প্রথম জিনিসটি TLS রেকর্ড নয়। এটি OpenVPN-এর হেডার, তার পরে হেডার যে চ্যানেলের কথা ঘোষণা করে তার বিষয়বস্তু। সেখানে একটি ClientHello আছে, শুধু শূন্য বাইটে নয়। পার্থক্য লক্ষ্য করতে কোনো ডিক্রিপশন লাগে না, কারণ আকৃতিই তা বলে দেয়।
ডিফল্টও এখানে গুরুত্বপূর্ণ। প্রবাহ UDP হয়ে 1194-এ যায়, যদি না প্রোফাইল TCP বেছে নেয়। দুই ক্ষেত্রেই বাইরের চেহারা টানেল, কোনো ওয়েব অনুরোধ নয়।
আকৃতি বদলানোর তিনটি সৎ উপায়
stunnel-এর মতো একটি TLS টার্মিনেটর দুই প্রান্তে একটি পোর্টে TLS গ্রহণ করে এবং ডিক্রিপ্ট করা প্রবাহ স্থানীয়ভাবে OpenVPN-কে দেয়, তাই নেটওয়ার্ক সেই পোর্টে TLS দেখে। যে প্রোটোকল প্রথম বাইট থেকেই TLS, সেটি আবার ভিন্নভাবে আচরণ করে: ocserv বাস্তবায়িত AnyConnect-সামঞ্জস্যপূর্ণ বিনিময় অনেক নেটওয়ার্কের ইতিমধ্যে প্রত্যাশিত কর্পোরেট রিমোট অ্যাক্সেসের মতো দেখায়। SSTP, যা Windows-এর সঙ্গে আসে, ভিন্ন পণ্যে একই বৈশিষ্ট্য রাখে।
Linux-এ SSH-এর -w অপশন একটি SSH সেশনের ভেতরে পয়েন্ট-টু-পয়েন্ট লিংক বহন করে, যা তখন কাজে লাগে যখন SSH-ই একমাত্র অনুমোদিত প্রোটোকল। SSH যদি ওই নেটওয়ার্ক থেকে আগেই কাজ করে তবে এটি চারটির মধ্যে সবচেয়ে সস্তা, আর না করলে সবচেয়ে কম উপযোগী।
এর কোনোটিই যা বদলায় না
এর কোনোটিই টানেল কী পর্যন্ত পৌঁছাতে পারে তা বদলায় না। এরা আটকানো ঠিকানাকে পৌঁছানোর যোগ্য করে না, কাউকে প্রমাণায়ন করে না, এবং রুট নির্ধারণ করে না।
একটি মোড়ক আপনাকে একটি উপাদানও খরচ করায়। দুটি লিসেনার ও দুটি কনফিগারেশন ফাইল মানে ব্যর্থতার দুটি জায়গা, আর দুটোই ব্যবহারকারীর আসন থেকে একই রকম দেখায়। একটি গ্রহণের আগে তার বাজেট ধরুন। সেশনটি এক গন্তব্যে একটি দীর্ঘস্থায়ী এনক্রিপ্টেড প্রবাহই থাকে, আর তার আয়তন ও সময় দৃশ্যমান থাকে।
আগে রোগনির্ণয় করুন, তারপর বেছে নিন
তাই আগে রোগনির্ণয় করুন। বাদ পড়া UDP-র উত্তর TCP মোড, আর চেনা স্বাক্ষরের উত্তর ভিন্ন প্রোটোকল বা মোড়ক। বাধা না জেনে টুল বেছে নেওয়াই মানুষকে তিনটি স্তর রক্ষণাবেক্ষণে নিয়ে যায়, যেগুলো একই কারণে সবই ব্যর্থ হয়।
যে নেটওয়ার্ক কেবল ওয়েব পোর্ট অনুমোদন করে, তা পছন্দকে 443-এ TLS-ভিত্তিক প্রোটোকলে সীমিত করে। তিনটিই একসঙ্গে প্রয়োগ করলে এমন স্ট্যাক হয় যা কেউ ডিবাগ করতে পারে না, তাই একটি জিনিস বদলে একই প্রবাহ আবার পরীক্ষা করুন।
এর কোনোটিই প্রযোজ্য না হলে সঠিক উত্তর হলো, এই নেটওয়ার্ক আপনার জন্য টানেল বহন করবে না। এটি একটি অনুসন্ধান, প্রচেষ্টার ব্যর্থতা নয়। আরও বিকল্প ঘুরে দেখা উপরের দিকে নেওয়া নীতি-সিদ্ধান্ত উল্টায় না।
এসবের সামনে একটি সীমা আছে। অন্যের নেটওয়ার্কে টানেল চালানোর অনুমতি একটি নীতি বিষয়, যা প্রক্রিয়াটি কাজ করে কি না তার থেকে আলাদাভাবে ঠিক হয়। এই তথ্যগুলো ব্যাখ্যা করে একজন পর্যবেক্ষক কী দেখেন, এবং তারা অনুমতি দেয় না।