রাউটেড OpenVPN টানেলে নামের অনুসন্ধান কেন ব্যর্থ হয়

হোস্ট ঠিকানা দিয়ে ping-এর উত্তর দেয় কিন্তু নাম দিয়ে প্রতিটি অনুসন্ধানে ব্যর্থ হয়। টানেল চালু আছে এবং রুটও বিদ্যমান, তাই স্বাভাবিক সিদ্ধান্ত হলো VPN ভুলভাবে কনফিগার করা হয়েছে। আরও কাজে লাগা সিদ্ধান্ত হলো, অনুসন্ধানটি কখনোই রাউটযোগ্য ছিল না: রাউটেড টানেল unicast IP বহন করে, অথচ কোয়েরিটি ছিল একটি ব্রডকাস্ট, যা ওপাশে নেই এমন একটি সেগমেন্ট খুঁজছিল। স্তরের অমিলটি দেখা গেলে সমাধানগুলো নিজেরাই খরচ অনুসারে সাজিয়ে নেয়।

ভ্রান্ত ধারণা: নাম ব্যর্থ হয় বলেই টানেল নষ্ট

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

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

সমাধানের নাম বলার আগে ব্যর্থ প্রক্রিয়াটির নাম বলুন। ব্রডকাস্ট ব্যবহার করা অনুসন্ধানের সেগমেন্ট দরকার, আর রিজলভার ব্যবহার করা অনুসন্ধানের দরকার জিজ্ঞাসা করার একটি ঠিকানা।

TUN কী বহন করে আর কী করে না

TUN ডিভাইস একটি IP ইন্টারফেস, আর এটিই এটিকে রাউটযোগ্য করে তোলে। OpenVPN ক্লায়েন্টকে একটি ঠিকানা ও কতগুলো রুট দেয়, এরপর ক্লায়েন্ট পিয়ারের কাছে ডেটাগ্রাম পাঠায়। ওই মডেলে এমন কোনো শেয়ারড লিংক তৈরি হয় না যেখানে প্রতিটি হোস্ট প্রতিটি ফ্রেম শোনে।

আবিষ্কারের ট্রাফিক ওই মডেলে একেবারেই খাপ খায় না। পুরোনো Windows নামের কোয়েরি, SSDP ঘোষণা আর mDNS অনুরোধ একটি গন্তব্যের বদলে সেগমেন্টের সবাইকে পাঠানো হয়। রাউটেড লিংকে পাঠানোর মতো কোনো «সবাই» নেই। ওই প্রতিটি প্রক্রিয়াই একটি শেয়ারড মাধ্যম ধরে নেয়।

তাই টানেল সুস্থ থাকতে পারে, অথচ আবিষ্কার পুরোপুরি ব্যর্থ হতে পারে। কেউ VPN ডাউন বলে জানালে এই বাক্যটিই ধরে রাখতে হবে।

ব্রিজিং কাজ করে সীমানা সরিয়ে দিয়ে

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

নিরাময় হলো রাউটিং সীমানা সরানো, টানেলের ভিতরে নামের কোনো নতুন সামর্থ্য নয়। সেগমেন্ট যা ব্রডকাস্ট করে, তার সবকিছু এখন লিংকও পেরোয়।

ছোট ল্যাবের জন্য এটি ন্যায্য বিনিময়। বিক্ষিপ্ত কর্মীবাহিনীর ক্ষেত্রে এটি বিরল।

DNS ও WINS পুশ করাই সংকীর্ণ সমাধান

ক্লায়েন্টকে জিজ্ঞাসা করার একটি নির্দিষ্ট জায়গা দিন। dhcp-option DNS ও dhcp-option DOMAIN অভ্যন্তরীণ নামগুলোকে জোন চেনে এমন সার্ভারের দিকে পাঠায়, আর NetBIOS-এর উপর নির্ভর করা Windows ক্লায়েন্ট একইভাবে একটি WINS সার্ভার পেতে পারে। টানেল রাউটেড থাকে আর সেগমেন্ট নিজের জায়গাতেই থাকে।

দুটি শর্ত ঠিক করে এটি কাজ করবে কি না। উল্লেখিত সার্ভারকে জোনের জন্য উত্তর দিতে হবে, আর কোয়েরিকে টানেল দিয়ে অনুমোদন করতে হবে।

রিজলভার পরীক্ষা করুন ক্লায়েন্ট থেকে, সার্ভারের নিজের শেল থেকে নয়। স্থানীয়ভাবে কাজ করা রিজলভার টানেল কী বহন করে সে সম্পর্কে কিছুই বলে না।

কোন স্তরটি ব্যর্থ হলো তা বের করুন

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

মাল্টিকাস্ট একই দেয়ালের পিছনে। 224.0.0.251-এর মতো গ্রুপ ডিফল্টভাবে রাউটেড টানেল পেরোয় না, আর গ্রুপের জন্য একটি রুট যথেষ্ট নয় যদি মাল্টিকাস্ট-সচেতন পথ বা LAN-এ একটি রিফ্লেক্টর না থাকে।