কেন OpenVPN-এর UDP উত্তর ভুল ঠিকানা থেকে আসে

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

উৎস পরিবর্তিত হলে ক্লায়েন্ট কী দেখে

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

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

multihome অপশনটি আসলে কী করে

নির্দেশনাটি কনফিগারেশন ফাইলে multihome হিসেবে এবং কমান্ড লাইনে --multihome হিসেবে লেখা হয়, আর এটি UDP সার্ভারকে ক্লায়েন্টের প্যাকেট যে ঠিকানায় পৌঁছেছে সেখান থেকে উত্তর দিতে বাধ্য করে। কের্নেল গ্রহণের সময় মূল গন্তব্য ঠিকানাটি অতিরিক্ত তথ্য হিসেবে দেয়, এবং OpenVPN সেই মানটিকে উত্তরের উৎস হিসেবে ব্যবহার করে। ফলে ওয়াইল্ডকার্ড ঠিকানায় শোনা একটি সার্ভার, IPv4-এর জন্য local 0.0.0.0 বা IPv6-এ তার সমতুল্য, এমন আচরণ করে যেন প্রতিটি ক্লায়েন্ট একটি আলাদা লিসেনারে পৌঁছেছে। পাবলিক ঠিকানা দিয়ে আসা ক্লায়েন্টরা পাবলিক ঠিকানা থেকে উত্তর পায়, আর অভ্যন্তরীণ ঠিকানার ক্লায়েন্টরা সেই ঠিকানা থেকেই পায়। প্যাকেটের পথে আর কিছুই নড়ে না: রুট, ফিল্টার নিয়ম আর টানেল কনফিগারেশন ঠিক যেমন ছিল তেমনই থাকে।

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

কখন নির্দিষ্ট স্থানীয় ঠিকানা ভুল ডিফল্ট

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

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

বাইরে থেকে উত্তরের উৎস প্রমাণ করুন

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

রুটিং, আবিষ্কার ও ফিল্টারিং আলাদা থাকে

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

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