VPN অ্যাডাপ্টার /32 দেখায়: এর মানে একটিই গন্তব্য নয়

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

মিথ: হোস্ট মাস্ক মানে একটি পৌঁছানোযোগ্য হোস্ট

একটি /32 বরাদ্দ ইন্টারফেসকে বলে লিংকের এই প্রান্তের ঠিকানা কোনটি, আর পয়েন্ট-টু-পয়েন্ট লিংকে এটিই এর পুরো অর্থ। সহকর্মীর ঠিকানা আলাদা একটি ফিল্ড, আর সহকর্মীর ওপারে কী আছে তা বলা রুটগুলো আবার আলাদা। মাস্কে দূরবর্তী নেটওয়ার্কের কোনো বর্ণনা নেই, কারণ দূরবর্তী নেটওয়ার্ক বর্ণনা করা হয় মাস্কে নয়। এটিকে পৌঁছানোর সীমা হিসেবে পড়া মানে নিজের বাড়ির নম্বরকে আপনি যে ঠিকানা সব দেখতে পারেন তার তালিকা হিসেবে পড়া।

এই বিভ্রান্তির একটি বাস্তব উৎস আছে: Ethernet-এ হোস্ট মাস্ক সত্যিই সেই সেগমেন্টে একটি ঠিকানা বোঝাত। টানেল কোনো Ethernet সেগমেন্ট নয়, এবং এর ভেতর দিয়ে কী যাবে তা ঠিক করে ক্লায়েন্টের রাউটিং টেবিল, মাস্ক নয়। এই কারণেই একই /32 একটি সম্পূর্ণ ডেটা সেন্টারের সামনে বসতে পারে।

ঠিকানা ও রুটকে আলাদা বস্তু হিসেবে পড়ুন

ইন্টারফেস ও টেবিল একসঙ্গে ছাপুন, তারপর সেগুলোকে দুটি প্রশ্নের দুটি উত্তর হিসেবে পড়ুন। ঠিকানা বলে এই প্রান্তটি কে; রুট বলে ট্রাফিক কোথায় যেতে পারে। তৃতীয় প্রশ্ন—গেটওয়ে কোন গন্তব্য অনুমোদন করে—ক্লায়েন্টে আদৌ দেখা যায় না। ঠিক এই কারণেই iproute2-এর ঠিকানা রেফারেন্স লোকাল, পিয়ার ও প্রিফিক্স-রুট ফিল্ডগুলো আলাদাভাবে বর্ণনা করে।

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

লুকআপ ভুল ইন্টারফেস দেখালে থামুন। এটি ক্লায়েন্টের রাউটিং সমস্যা, এবং এটি ক্লায়েন্টেই ঠিক হয়।

মাস্ক চওড়া করলে কেন সাধারণত আরও খারাপ হয়

অফিস LAN-এর মতো দেখাতে বরাদ্দটি /24-এ বদলালে লিংকে একটি প্রিফিক্স তৈরি হতে পারে: কার্নেল এখন মনে করে পুরো /24 সরাসরি টানেল ইন্টারফেসে যুক্ত। গেটওয়ে দিয়ে যাওয়ার কথা থাকা ঠিকানার ট্রাফিক তখন এমনভাবে পাঠানো হয় যেন প্রতিবেশী লিংকেই আছে। ফলাফল একটি কালো গর্ত, যা সার্ভার বিকলের মতো দেখায়।

এটি আসল সমস্যাটিও ঢেকে দেয়, যা হলো অনুপস্থিত রুট বা গেটওয়েতে অনুপস্থিত অনুমতি। এর কোনোটিই চওড়া মাস্ক তৈরি করে না, আর দুটোই পরিবর্তনের পরেও টিকে থাকে। যদি ডিজাইনে ইন্টারফেসে বড় প্রিফিক্স দরকার হয়, তবে তা ব্যবহৃত ইন্টারফেস মডেলের সিদ্ধান্ত, যা ডকুমেন্টেশন হাতে নিয়ে নিতে হয়। অন্য পণ্যের স্ক্রিনশট থেকে মাস্ক কপি করা সেই সিদ্ধান্ত নয়।

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

যখন রুট ঠিক থাকে আর প্রবাহ তখনো ব্যর্থ হয়

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

যন্ত্র-পরিচালিত সেবায় নেটওয়ার্ক বস্তু ও গ্রুপ অনুমতি তাদের মালিকের কাছে রাখুন। ক্লায়েন্টকে কী পৌঁছাতে বলা হয়েছে আর তাকে কী ব্যবহারের অনুমতি দেওয়া হয়েছে—এ দুটি আলাদা সেটিং, প্রায়ই আলাদা পর্দায়। একটি বদলে অন্যটি পরীক্ষা করাই হলো একটি টিকিট দুই দলের মধ্যে ঘুরে বেড়ানোর উপায়।

যে মিথ বাদ দিতে হবে তা হলো মাস্কটি পৌঁছানোর সীমা। ঠিকানা, রুট ও গেটওয়ে নীতি—তিনটি আলাদা সত্য হিসেবে পড়ুন, তাহলে /32 আর সীমাবদ্ধতা মনে হবে না, সাধারণ টানেল বরাদ্দ মনে হতে শুরু করবে।