تتصل مراقبة المنافذ بشكل متكرر بمضيف ومنفذ محددين، مثل db01:5432، للتأكد من أن الخدمة تقبل الاتصالات فعلًا. وهي تقع بين ping وفحوصات HTTP وتجيب عن سؤال واحد: هل العملية في وضع الاستماع، ويمكن الوصول إليها عبر مسار الشبكة، وتقبل الاتصالات بسرعة كافية؟ ويُعدّ ذلك مهمًا لموثوقية الشبكة لأن كثيرًا من الأعطال يقع بينما المضيف لا يزال يعمل، ولا يرصدها إلا فحص على مستوى المنفذ.
كيف يعمل فحص المنفذ
يفتح فحص منفذ TCP اتصالًا كما يفعل أي عميل: SYN ثم SYN-ACK ثم ACK، ثم إغلاق الاتصال. وتندرج النتيجة ضمن إحدى ثلاث حالات:
- Open (مفتوح): اكتملت المصافحة، أي أن هناك خدمة تستمع ويمكن الوصول إليها.
- Closed (مغلق): ردّ المضيف بحزمة إعادة تعيين (RST)، أي أنه قابل للوصول لكن لا شيء مرتبط بهذا المنفذ.
- Filtered (مُرشَّح): لم يصل أي رد قبل انتهاء المهلة، وغالبًا ما يكون السبب أن جدار حماية أو security group أو قائمة ACL أسقط الحزمة بصمت.
لا يملك UDP مصافحة، لذا يرسل الفحص حزمة استكشاف ويعدّ أي رد صالح نجاحًا. وتعني رسالة ICMP «port unreachable» أن المنفذ مغلق، بينما يبقى الصمت غامضًا. لذلك تعمل فحوصات UDP على أفضل وجه مع حمولة خاصة بالبروتوكول، مثل استعلام DNS حقيقي إلى المنفذ 53.
ويهم زمن الاتصال أيضًا: فالمصافحة التي تقفز من 20 ms إلى 800 ms تمثل إنذارًا مبكرًا حتى وإن ظل المنفذ يظهر مفتوحًا.
موقع مراقبة المنافذ بين ping وHTTP
انظر إلى أنواع الفحص الثلاثة بوصفها طبقات: المضيف، والخدمة، والتطبيق.
| الفحص | السؤال الذي يجيب عنه | النقطة العمياء المعتادة |
|---|---|---|
| Ping (ICMP) | هل يمكن الوصول إلى المضيف عبر الشبكة؟ | تعطل الخدمة بينما يواصل نظام التشغيل الرد |
| المنفذ (TCP/UDP) | هل تقبل هذه الخدمة الاتصالات؟ | التطبيق يعيد أخطاء بعد إنشاء الاتصال |
| HTTP/HTTPS | هل يعيد التطبيق الاستجابة الصحيحة؟ | الخدمات غير المعتمدة على HTTP مثل قواعد البيانات وSMTP وMQTT |
وبالنسبة إلى الخدمات التي لا تعمل عبر HTTP، مثل PostgreSQL وRedis وSMTP وSSH وRabbitMQ، يكون فحص المنفذ غالبًا أكثر إشارات التوفر الخارجية مباشرة.
أعطال الموثوقية التي ترصدها مراقبة المنافذ
تفلت هذه الحوادث من ping ولا تظهر إلا على مستوى المنفذ:
- تعطل الخدمة مع بقاء المضيف قيد التشغيل. أُنهيت قاعدة البيانات بسبب نفاد الذاكرة (OOM)، لكن النواة لا تزال ترد على ping. ويتحول المنفذ إلى «مغلق» خلال فترة فحص واحدة.
- تغيير في جدار الحماية أو security group. تغيير في البنية التحتية كرمز (Infrastructure as Code) يحجب حركة المرور إلى المنفذ 5432. يبقى المضيف مستجيبًا لـ ping بينما يصبح المنفذ «مُرشَّحًا».
- ربط المستمع بواجهة خاطئة. ترتبط الخدمة بـ
127.0.0.1بدلًا من0.0.0.0. تبدو سليمة محليًا، لكن الفحوصات البعيدة ترى المنفذ مغلقًا. - بطء قبول الاتصالات أو استنزاف المنافذ. امتلاء قائمة انتظار القبول (accept backlog) أو تراكم اتصالات TIME_WAIT أو تشبّع مجمع الاتصالات يؤدي إلى تعثر المصافحات. وغالبًا ما يكون ارتفاع زمن الاتصال أول عرض ظاهر.
- خدمات غير متوقعة. منفذ يُفترض أن يكون مغلقًا، مثل واجهة تصحيح أخطاء، يظهر فجأة مفتوحًا، وهي مشكلة تمس الموثوقية والأمان معًا.
ما لا ترصده مراقبة المنافذ
المنفذ المفتوح ليس دليلًا على سلامة الخدمة. فقد يقبل خادم الويب الاتصالات ويعيد أخطاء 500، وقد تقبل قاعدة البيانات الاتصالات وترفض الاستعلامات لامتلاء القرص، وقد يقدّم مستمع TLS شهادة منتهية الصلاحية. كما أن فحوصات المنافذ لا تخبرك شيئًا عن بطء الاستعلامات أو صحة البيانات. لذا اجمعها مع فحوصات HTTP وAPI وSSL للطبقات الأعلى، ومع ping للشبكة في الطبقة الأدنى.
إرشادات عملية للإعداد
- راقب كل منفذ خدمة يمكن الوصول إليه من الخارج، إضافة إلى المنافذ الداخلية التي تعتمد عليها المسارات الحرجة.
- استخدم فترات فحص من 30 إلى 60 ثانية لخدمات الإنتاج، وتكفي عادةً فترة من دقيقة إلى 5 دقائق للأنظمة الأقل أهمية.
- اضبط مهلة الاتصال على نحو 5 إلى 10 ثوانٍ، وأطلق التنبيه عندما يتجاوز زمن الاتصال خط الأساس بوضوح، لا عند الفشل فقط.
- أكّد الأعطال من أكثر من موقع قبل إرسال التنبيه، كي لا يتسبب مسار شبكة واحد معطّل في إنذار كاذب.
- احتفظ بخط أساس للمنافذ التي يجب أن تكون مفتوحة وتلك التي يجب أن تكون مغلقة، ونبّه عند أي انحراف في الاتجاهين.
توفر مراقبة المنافذ من UpScanX فحوصات TCP وUDP، وتحديد بصمة الخدمات مع اكتشاف الإصدار، والتحقق من الاستجابة وفق كل بروتوكول، وتتبع زمن الاتصال من أكثر من 15 موقعًا حول العالم. كما تقارن UpScanX حالة المنافذ بخط الأساس الخاص بإعداداتك للإبلاغ عن الخدمات غير المتوقعة، وترسل التنبيهات عبر Email وSlack وTelegram وMicrosoft Teams وWebhook. ولمزيد من التفاصيل، راجع كيف تعمل مراقبة المنافذ.
أبرز النقاط
- تتحقق مراقبة المنافذ من أن خدمة محددة تقبل الاتصالات، لا من مجرد إمكانية الوصول إلى المضيف.
- ترصد العمليات المتعطلة وتغييرات جدار الحماية وعناوين الربط الخاطئة وتشبّع الاتصالات التي يغفل عنها ping.
- تشير الحالات «مفتوح» و«مغلق» و«مُرشَّح» إلى أسباب جذرية مختلفة، مما يسرّع التشخيص.
- لا تتحقق من سلوك التطبيق، لذا اجمعها مع فحوصات ping وHTTP وSSL لتغطية شاملة.