لماذا يتغير فحص المنافذ عند تشغيله باستخدام sudo

لا يرسل Nmap دائمًا الحزمة التي تعتقد أنك طلبتها. عندما تكون المقابس الخام غير متاحة، فإنه يستبدل فحص SYN الافتراضي بفحص TCP connect، لذا يمكن أن يجيب التشغيل كمستخدمك العادي والتشغيل تحت sudo عن أسئلة مختلفة حول المنفذ نفسه. تبدو النتائج مشكلة صلاحيات، لكنها في الغالب تغيّر في الطريقة. جعل الطريقة صريحة هو السبيل الوحيد لمقارنة التشغيلين أصلًا.

فحصان، منفذ واحد، مساران مختلفان في الشيفرة

يبني فحص SYN ترويسة TCP بنفسه، ويرسلها من مقبس خام، ويقرأ الرد من الشبكة قبل أن يسجّل مكدس TCP في النواة أي اتصال مكتمل. أما فحص connect فيطلب من نظام التشغيل فتح مقبس عادي ويبلغ عن كل ما يعيده connect(). يمكن لكليهما وصف المنفذ بأنه مفتوح، لكن واحدًا فقط يترك محاولة نصف مفتوحة، وواحدًا فقط يخضع لسياسة على مستوى المقبس مرتبطة بالعملية المرسلة.

يحتاج المسار الخام إلى CAP_NET_RAW، ولهذا يتراجع الفحص الافتراضي بصمت عند غياب هذه القدرة. يوثّق مرجع تقنيات الفحص الخاص بـ Nmap هذا الاستبدال: فحص connect هو البديل لأنه لا يحتاج إلى أي صلاحيات خاصة على الإطلاق. يحدث التبديل دون تحذير في معظم التشغيلات، وهذا ما يجعله عرضة لسوء القراءة. بمجرد أن تعرف أن البديل موجود، يتوقف القول «مفتوح كجذر، مغلق كمستخدم» عن أن يبدو خللًا في الصلاحيات ويبدأ في أن يبدو قياسين مختلفين.

ما يغيّره sudo فعليًا في الفحص

إعادة الصلاحيات تُرجع مسار المقبس الخام، وهذا يغيّر أكثر من الحكم. اختيار منفذ المصدر وتوقيت الحزم وسلوك إعادة الإرسال وطريقة تصنيف الرد المفلتر تأتي كلها من شيفرة مختلفة. الجهاز الوسيط الذي يحدّ من معدل SYN يعامل التشغيلين بشكل غير متساوٍ حتى عندما يكون المضيف الهدف متطابقًا.

يختلف التسجيل على جانب الهدف أيضًا. المصافحة المكتملة مرئية للخدمة ولأي محاسبة للمقابس، بينما الفحص النصف مفتوح المعاد ضبطه غالبًا ليس كذلك. وإذا قارنت التشغيلات مقابل مضيف تقرأ سجلاته أيضًا، فإن جزءًا من الاختلاف الذي تراه هو الملاحظة نفسها.

أبقِ الطريقة ثابتة في التشغيلين

افرض التقنية نفسها في كلا الاستدعاءين وستبدأ المقارنة تعني شيئًا. العلم -sT يطلب فحص connect صراحةً، و -Pn يزيل اكتشاف المضيف، و -n يزيل حل الأسماء، و -p واحد يزيل فروق قائمة المنافذ.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

استبدل العنوان والمنفذ بمضيف مصرح لك باختباره؛ نطاق التوثيق أعلاه عنصر نائب وليس هدفًا. إذا اتفق التشغيلان الآن، فالاختلاف الأصلي جاء من طريقة الفحص. وإذا استمرا في الاختلاف، فهناك شيء آخر يصنّف حركة المرور، والقسم التالي هو مكان البحث.

سياق الحساب ليس مجرد علم صلاحيات

يمكن لنشر VPN أن يصنّف الحزم حسب UID أو cgroup أو قاعدة مرتبطة بالعملية التي فتحت المقبس. ثم تخرج حركة الجذر وحركة المستخدم عبر جداول توجيه مختلفة أو تصيب مجموعات قواعد مختلفة، ولا يستطيع أي قدر من انضباط طريقة الفحص التوفيق بينها.

افحص السياسة بدلًا من الصلاحية. على Linux، يعبّر nftables عن ذلك بـ meta skuid ويعبّر iptables عن ذلك بمطابقة المالك، ويمكن لأي منهما إرسال UID واحد عبر نفق بينما يواصل الآخر استخدام المسار الافتراضي الفيزيائي.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

أثبت الفحص قبل مقارنة النتائج

قبل استخلاص النتائج، أثبت أي فحص جرى. يسمّي Nmap التقنية في مخرجاته، ويضيف --reason الدليل وراء كل حالة، وهو الجزء الذي يخبرك هل اكتملت المصافحة فعلًا.

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

التشغيلان اللذان يبلغان عن الحالة نفسها لأسباب مختلفة ليسا تناقضًا، والتشغيلان اللذان يبلغان عن حالتين مختلفتين للسبب نفسه يشيران إلى التوجيه أو السياسة لا إلى الفحص. أبقِ الهدف والمنفذ والنطاق والتوقيت متطابقة، ثم غيّر متغيرًا واحدًا في كل مرة. تشغيل الخدمة كجذر ليس إصلاحًا لعدم تطابق السياسة؛ التعبير عن السياسة المقصودة عبر مالك الخدمة هو الإصلاح.