VPN দিয়ে ping: প্রতিধ্বনি উত্তরের নিয়ম কেন ফেরার পথ মিস করে

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

প্যাকেট পোর্ট নয়, ধরন বদলায়

প্রতিধ্বনি অনুরোধ হলো ICMP ধরন 8, কোড 0, যা একটি শনাক্তকারী ও একটি ক্রম নম্বর বহন করে। উত্তর হলো ধরন 0, কোড 0, একই শনাক্তকারী ও ক্রম নম্বরসহ, এবং IP প্রান্ত দুটি বদলানো। RFC 792 ওই ফিল্ডগুলো নির্ধারণ করে, আর শনাক্তকারীই প্রেরককে উত্তরগুলো তার নিজের অনুরোধের সঙ্গে মেলাতে দেয়।

যা নেই সেটিও সমান গুরুত্বপূর্ণ: কোনো TCP বা UDP হেডার নেই, তাই অনুমোদন করার মতো কোনো পোর্ট নেই। প্রতিধ্বনি উত্তরের জন্য পোর্ট উল্লেখ করা নিয়ম এমন একটি প্যাকেট বর্ণনা করে যা কখনো অস্তিত্বে আসবে না। VPN ping টিকিটে এটিই সবচেয়ে সাধারণ ভুল। নিয়মটি নির্দিষ্ট দেখায়, কিছুরই প্রযোজ্য হয় না, আর ব্যর্থতাটিকে ঠিক যেখানে ছিল সেখানেই রেখে দেয়।

তিনটি প্রেক্ষাপট প্যাকেটের ভাগ্য নির্ধারণ করে

ping যদি দূরের LAN-এর কোনো হোস্ট লক্ষ্য করে, অনুরোধটি গেটওয়ে ফরওয়ার্ড করবে। যদি এটি গেটওয়ের নিজের কোনো ঠিকানা লক্ষ্য করে, তবে তা লোকাল ইনপুট পথে শেষ হয়। আর যদি গেটওয়ে নিজেই ping শুরু করে, প্যাকেটটি তার নিজের আউটপুট পথে শুরু হয় এবং ফরওয়ার্ডিং সিদ্ধান্ত একেবারেই পেরোয় না।

এই তিন প্রেক্ষাপটের নিয়ম-শৃঙ্খল ও কাউন্টার আলাদা, আর তাদের এক হিসেবে ধরা—এটাই কারণ যে „ফায়ারওয়াল ICMP অনুমোদন করে“ বলেও ping ব্যর্থ হতে পারে। বাইরের টানেল চতুর্থ প্রেক্ষাপট: VPN লিসেনার অনুমোদন করলে ডিক্যাপসুলেট হওয়া ভেতরের অনুরোধ স্বয়ংক্রিয়ভাবে অনুমোদিত হয় না, আর ভেতরের অনুমোদন বাইরের টানেল ওপরে আছে কি না সে সম্পর্কে কিছু বলে না।

স্টেটফুল ও স্টেটলেস ফিল্টার উত্তরটি ভিন্নভাবে সামলায়

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

কিছু লেখার আগে যাচাই করুন পণ্যটি আসলে কোন মডেল প্রয়োগ করে। প্রতিধ্বনি অনুরোধের নিয়ম অগত্যা প্রতিধ্বনি উত্তর ঢাকে না, আর ICMP কোয়েরি অনুসরণ করা পণ্যও অন্য ইন্টারফেসে আসা উত্তরের ক্ষেত্রে ভিন্ন নীতি প্রয়োগ করতে পারে।

যা অনুমোদন করছেন তার পরিধি ঠিক করুন। যেকোনো জায়গা থেকে সব প্রতিধ্বনি উত্তর অনুমোদন করা স্টেটফুল সংযোগ সম্পূর্ণ করার সমান নয়, আর ধরন নম্বর প্রেরককে প্রমাণ করে না।

অনুবাদ শনাক্তকারীও বদলায়

উৎস অনুবাদ যদি ইচ্ছাকৃত হয়, দূর প্রান্তের টাপল ক্লায়েন্ট যেটি পাঠিয়েছে তার সঙ্গে মেলে না। NAT ঠিকানার সঙ্গে সঙ্গে ICMP কোয়েরি শনাক্তকারীও অনুবাদ করতে পারে, তাই দুই দিকেই একই নম্বর দেখা উচিত বলে জোর দেওয়া মিথ্যা অমিল তৈরি করে।

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

ICMP ত্রুটি প্রতিধ্বনি নীতিতে মিলিয়ে ফেলবেন না

পথ MTU আবিষ্কারে ব্যবহৃত „ফ্র্যাগমেন্টেশন দরকার“ বার্তাটি প্রতিধ্বনি উত্তর নয়, আর তার পেলোড যে প্যাকেটটি তা উদ্রেক করেছে সেটি উদ্ধৃত করে। কেবল-প্রতিধ্বনি অনুমোদন যে ওই ত্রুটিগুলো চুপচাপ ফেলে দেয়, তা আকারের সমস্যাকে ঝুলে থাকা সংযোগে বদলে দেয়—যা সহায়তার ঠিক উল্টো।

একই সতর্কতা ঠিকানা পরিবারের ক্ষেত্রেও প্রযোজ্য। ICMPv6 ভিন্ন বার্তা ধরন ব্যবহার করে এবং IPv4-এ নেই এমন অপরিহার্য কাজ বহন করে, তাই এই নম্বরগুলো IPv6 নিয়মে কপি করা নিছক ভুল।

প্রতিধ্বনি বিনিময় কাজ করলে আসল অ্যাপ্লিকেশনটি আলাদাভাবে পরীক্ষা করুন। সফল ping একটি প্রোটোকলের এক আকারে এক গন্তব্যে যাওয়া-আসা প্রমাণ করে, আর HTTPS, SMB বা অন্য যেকোনো প্রবাহ অনুমোদিত ধরে নেওয়ার লাইসেন্স নয়।