VPN-এ Nmap-এর কাঁচা স্ক্যান ব্যর্থ, কিন্তু -sT সংযোগ কাজ করে?

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

সামর্থ্যকে টানেল থেকে আলাদা করুন

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

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

কোনো ফলাফলই দূরবর্তী সেবাকে বর্ণনা করে না। দুটোই এক পদ্ধতিতে এক পথ বর্ণনা করে, তাই সিদ্ধান্তের সাথে পদ্ধতি যুক্ত রাখুন।

একটি অনুমোদিত হোস্টে সংযোগ যাচাই চালান

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

এক লাইন, এক হোস্ট, এক পোর্ট, কোনো আবিষ্কার ধাপ নেই:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT পূর্ণ TCP সংযোগ বেছে নেয়, তাই এটি অ্যাপ্লিকেশন যে কার্নেল পথ ব্যবহার করে সেটাই চালায় এবং ক্যাপচার ড্রাইভার লাগে না। -Pn হোস্ট আবিষ্কার এড়িয়ে যায়; nmap তবুও স্থানীয় সেগমেন্টের লক্ষ্যের জন্য লিঙ্ক-লেয়ার রিজলিউশন করে, তাই ফ্ল্যাগটি শূন্য প্রাথমিক ট্রাফিকের প্রতিশ্রুতি নয়। --unprivileged nmap-কে বলে ধরে নিতে যে এর কোনো কাঁচা বা স্নিফিং অধিকার নেই, যা পদ্ধতি বদলায় এবং কিছুই দেয় না।

প্রতিটি ফ্ল্যাগকে একটি পরিবর্তন হিসেবে পড়ুন, মেরামত হিসেবে নয়

প্রতিটি অপশনকে পদ্ধতি সম্পর্কে একটি বক্তব্য হিসেবে ধরে নিন। -sT, -Pn বা --unprivileged এর কোনোটিই রুট যোগ করে না, দূরবর্তী ফায়ারওয়াল খোলে না বা সার্টিফিকেট যাচাই করে না। সংযোগ স্ক্যান একটি বাস্তব হ্যান্ডশেকও শেষ করে যা সেবা লগ করে, তাই অনুমোদিত যাচাই আর অননুমোদিত সুইপ সার্ভারের দিক থেকে কেবল পরিধি ও গতিতে আলাদা দেখায়। আউটপুট বদলানো পর্যন্ত অপশন স্তূপ করা মানে পদ্ধতির সমস্যাকে নেটওয়ার্ক অনুসন্ধান হিসেবে লিখে ফেলা।

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

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

পরিবহন ফলাফলে থামুন, তারপর সেবা পরীক্ষা করুন

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

এরপর সেবার নিজস্ব ক্লায়েন্ট ব্যবহার করুন যাতে TLS পরিচয় ও অ্যাপ্লিকেশনের আচরণ আলাদা ঘটনা হিসেবে দেখা যায়:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

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

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