UDP স্ক্যান বলছে ফিল্টার করা: আপনার WireGuard সঙ্গী কি সত্যিই বন্ধ?

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

এর বদলে ক্লায়েন্ট থেকে বাইরের দিকে কাজ করুন, এবং স্ক্যানকে কয়েকটি দুর্বল ডেটা বিন্দুর একটি হিসেবে ধরুন।

স্ক্যানার কী দেখতে পারে আর কী পারে না

একটি UDP স্ক্যানার একটি পেলোড পাঠায় এবং অপেক্ষা করে। যদি ICMP port-unreachable ফিরে আসে, সে পোর্টটি বন্ধ বলে জানাতে পারে। যদি কিছুই ফিরে না আসে, ফলাফল নকশার দিক থেকেই অস্পষ্ট: ফিল্টার করা পথ, অনুপস্থিত হোস্ট এবং চলমান সেবা যা পেলোড উপেক্ষা করেছে, সবাই একই নীরবতা তৈরি করে। তিনটি ভিন্ন অবস্থা, একটি আউটপুট স্ট্রিং।

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

একই পোর্ট নম্বরে TCP পরীক্ষা কোনো সম্পর্কিত কিছু যাচাই করে না। এটি অন্য একটি শ্রোতাকে চালায় যার অস্তিত্ব নাও থাকতে পারে, আর তার অস্বীকৃতি UDP সম্পর্কে কিছুই বলে না।

তাই খোলা ফিল্টার করা অবস্থাগুলো আপনার সার্ভারের চেয়ে স্ক্যানারের অনিশ্চয়তাকে বেশি নিখুঁতভাবে বর্ণনা করে।

আসল ক্লায়েন্টকে প্রোফাইল থেকে ভেতরের দিকে হাঁটুন

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

তারপর তৃতীয় জায়গা থেকে আলাদা স্ক্যান চালানোর বদলে, একটি অনুমোদিত চেষ্টা চলাকালীন সার্ভারের দিক দেখুন:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

প্রথম কমান্ড প্রতিটি সঙ্গীর সর্বশেষ হ্যান্ডশেক জানায়, যা প্রমাণিত বিনিময় সম্পন্ন হওয়ার সরাসরি প্রমাণ। দ্বিতীয়টি দেখায় শ্রোতার জন্য প্যাকেট আদৌ পৌঁছায় কি না, আর এটি এক ধাপে পথের সমস্যাকে কনফিগারেশনের সমস্যা থেকে আলাদা করে।

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

যখন আপনি সার্ভার পরিচালনা করেন তখন সেখানেই সম্পর্ক জোড়া দিন

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

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

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

স্ক্যানের ফল সৎভাবে পড়া

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

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

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