পিং এক দিকেই কাজ করে: কেন Windows সার্ভারের ইকো ফেলে দেয়

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

দুই দিক, দুই ভিন্ন সিদ্ধান্ত

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

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

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

প্যাকেট অদৃশ্য হওয়া পর্যন্ত অনুসরণ করুন

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

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

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

ICMP খোলার বদলে একটি নিয়ম সীমিত করুন

কিছু লেখার আগে অ্যাডাপ্টার ও তার বর্তমান ক্যাটাগরি চিহ্নিত করুন, কারণ দুটিই আপনি যে পরিধি স্থির করতে যাচ্ছেন তাতে আসে। ওই উপনামটি Windows ইন্টারফেসের নাম, যা আপনি আমদানি করা VPN প্রোফাইলের নাম নাও হতে পারে। নিচের কমান্ডগুলো কী আছে তা তালিকাভুক্ত করে, তারপর প্রয়োগ না করেই একটি সীমিত নিয়মের প্রিভিউ দেখায়।

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

নিয়মটি যা ঢাকে না

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

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

ফলাফল সঠিক দিক থেকে পড়ুন

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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