لماذا تتغير نتائج فحص المنافذ خلف مخرج VPN؟
غيّر المخرج وقد يجيب المنفذ بشكل مختلف دون أن تتحرك الخدمة. افصل ملاحظة المسار عن الجرد الذي تحتاجه فعليًا.
شغّل فحص المنفذ نفسه من خط مكتب ومن مخرج VPN، وقد يختلف الجوابان بشأن عنوان لم يغيّره أحد. تأتي هذه الفجوة من المسار ومن المضيف الذي ردّ، لا من كون الخدمة تعمل أو متوقفة. ثلاثة أسئلة تفصل بين هذه التفسيرات: ما الذي طلبه الفحص فعلًا، وأي مضيف أجاب عنه، وما الذي سجّله خادمك أنت. تناوبها بهذا الترتيب واكتب كل جواب قبل الانتقال إلى التالي.
أصلح الفحص قبل أن تقارن تشغيلين
لا يمكن مقارنة كلمة حالة إلا بكلمة حالة أخرى إذا خرجتا من التجربة نفسها. خمسة حقول تثبّت ذلك: عنوان المصدر الذي رآه الطرف البعيد، والوجهة المستقرّة، والمنفذ، ونوع الفحص، والوقت. غيّر أيًّا منها فتكون قد أجريت تجربة ثانية بدلًا من قياس الأولى مرتين.
افحص المصدر قبل أي شيء آخر، لأن عميل VPN قد يكون قيد التشغيل بينما تمرّ الحركة من الواجهة الفيزيائية. اسأل الطرف البعيد عمّا يراه، ثم اسأل النواة عن الواجهة التي اختارتها:
curl -s https://ifconfig.me
ip route get 203.0.113.20عنوانان على شبكتين مختلفتين يعنيان أن التفسير في متناول اليد، وبقية هذه الفحوصات ستؤكده فقط. حين يتفقان، التقط الفحص مع تفعيل علامة السبب، لتعود الحالة مرتبطة بتفسير بدلًا من أن تقف وحدها ككلمة مجرّدة. ينتمي نوع الفحص إلى ذلك السجل أيضًا، لأنه يصف ما طُلب لا ما عاد. والحالة بلا مصدر ولا طريقة ولا طابع زمني لا يمكن مقارنتها بأي شيء:
nmap -sT -p 443,8443 --reason 203.0.113.20احتفظ بذلك الخرج بجوار السجل بدلًا من وضعه في مخزن تمرير لا يراه الشخص التالي. فحصان صادقان يختلفان ليسا خلافًا إلا حين لا يكتب أحد الشروط. وبعد تثبيت الشروط، إما أن تتطابق النتائج وتُغلق المسألة، وإما أن تختلف فيكون الاختلاف حقيقة عن المسار.
اكتشف أي مضيف أنهى المصافحة
المصافحة المكتملة تثبت أن مضيفًا ما أكملها، وهذا المضيف ليس بالضرورة العملية التي تفكر فيها. يمكن لموازن أحمال أو وكيل عكسي أو وكيل SYN أن يجيب قبل أن يشارك الخادم الحقيقي، وهذا تصميم عادي لا عَرَض. والشهادة الصالحة للاسم المتوقّع لا تضيّق ذلك أيضًا، لأن الشهادة تصف علاقة خدمة ولا تقول أي جهاز أنهى الاتصال.
يعتبر مرجع Nmap لحالات المنافذ ذلك أمرًا أساسيًا: تسجّل الحالة ما استطاع الفحص ملاحظته من حيث أُرسل، لا خاصية للمنفذ. اقرأ كلمة الحالة على هذا النحو فيبدو تشغيلان اختلفا متسقين لا متناقضين، بينما تنتقل المسألة من هل المنفذ مفتوح إلى من كان يقف أمامه.
أجب عن السؤال الثاني عند الواجهة الخلفية لا من الخارج. الواجهة الأمامية التي تقبل الاتصالات ثم تفشل في الوصول إلى مصبّها تنتج بالضبط الصورة الخارجية لخدمة سليمة بتطبيق بطيء. فقط سجل المصبّ نفسه يفصل بين الحالتين:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'يعرض سطر السجل عنوان العميل الذي رآه التطبيق فعلًا، ويعرض الأمر الثاني ما إذا كانت العملية التي تحتفظ بالمنفذ 443 هي تطبيقك أم شيء يقف أمامه. إن اختلف الاثنان بشأن عنوان الاتصال، فأنت تنظر إلى ساقين لطلب واحد ووجب أن يذكر ذلك في التذكرة.
افحص قواعدك قبل أن تلوم النفق
السياسة المقصودة هي السبب الأكثر شيوعًا لأن يجيب المنفذ على شبكة دون أخرى، وهي أقل التفسيرات إثارة للاهتمام. قواعد الوصول موجودة للسماح بمصدر واحد وإسقاط البقية، لذا فإن تغيير المخرج هو بالضبط الحدث الذي كُتبت له. لذا فإن حالة مختلفة عبر VPN لا تُظهر أن المزوّد يفحص الحركة. إنها تُظهر أن عنوان مصدرك أصبح مختلفًا، وهي دعوى أصغر بكثير.
هذه القواعد قابلة للقراءة على الخادم، فاقرأها بدلًا من التخمين في منتصف الشبكة. اسرد قواعد التصفية التي تذكر أيًا من نطاقي العناوين، ثم تحقّق مما إذا وصل الاتصال إلى الخادم الخدمي أصلًا:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113النتيجة الثانية الفارغة مفيدة، لأنه لم يصل شيء إلى الخادم الخدمي والمسألة تخص مرشّحًا أو مجموعة أمان أو المسار نفسه. أما الإصابة فتعني أن الخدمة رأت مصدرك واختارت جوابها، وهذا القرار مكتوب عادة في قاعدة يمكنك قراءتها. لا النتيجتان تدعم رواية عن المزوّد، وكلاهما أرخص في الفحص من التقاط حزم.
اقرأ النقل والشهادة والاستجابة كلًا على حدة
ثلاث طبقات تنتج ثلاث ملاحظات، والفحص الذي يختبر واحدة منها لا يمكنه الإبلاغ عن الأخريين. أبقِها أسطرًا منفصلة في السجل بدلًا من دمجها في حكم واحد، لأن كل سطر يفشل بطريقته ويخبرك نمط الفشل أين تنظر بعد ذلك.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
أمر واحد ينتج الصفوف الثلاثة الأولى تجاه خدمة تتحكم بها. ضع خرجه في السجل بجوار الفحص لا في رسالة دردشة:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/اقرأ الخرج بالترتيب: المصافحة تجيب عن سؤال النقل، وموضوع الشهادة يجيب عن سؤال الاسم، وجسم الاستجابة يجيب عن سؤال التطبيق. حين ينجح سطر المصافحة ولا ينجح سطر الاستجابة، فلديك واجهة أمامية بمصبّ معطوب لا منفذ محجوب. تلك تذكرة مختلفة عن التي فتحتها، ويستحق أن يُقال بوضوح.
أنهِ بكتابة أربع حقائق في التذكرة: عنوان المصدر، ونوع الفحص، والمضيف الذي أجاب، والوقت. كل ما تحتاجه مقارنة لاحقة يعيش في تلك الأربع، ومن يلتقط الحالة تاليًا لن يملك تاريخ طرفيتك. إن لم تستطع ملء الأربع، فالتشغيل لم ينته.