تحليل PCAP لـ TCP RST وإعادة تعيين الاتصال: من أغلق الاتصال ولماذا
كيفية تحليل TCP RST، وإعادة تعيين الاتصال بواسطة النظير، وإعادة التعيين بعد SYN، وإعادة التعيين أثناء TLS، وإعادة تعيين جدار الحماية، وإغلاق التطبيق، وأدلة التقاط الحزم.
يعد "إعادة تعيين الاتصال بواسطة النظير" خطأً شائعًا في عملاء HTTP وقواعد البيانات وأدوات TLS والوكلاء وتطبيقات TCP المخصصة. يبحث المستخدمون عن "تحليل TCP RST pcap"، و"إعادة تعيين الاتصال بواسطة نظير Wireshark"، و"RST بعد SYN"، و"إعادة تعيين اتصال TLS"، و"إعادة تعيين TCP لجدار الحماية" لأنهم بحاجة إلى معرفة من أنهى الاتصال وما إذا كانت إعادة التعيين جاءت من التطبيق أو نظام التشغيل أو جدار الحماية أو موازن التحميل أو الخادم.
TCP RST صريح. تقول "إحباط هذا الاتصال". الجزء الصعب هو الإسناد.
تعتبر جراحة PCAP مفيدة لأن تحقيقات إعادة التعيين تحتاج إلى تتبع نظيف ومركّز يتضمن الاتجاه والطوابع الزمنية وأرقام التسلسل وحزم كافية قبل إعادة التعيين.
أنماط إعادة التعيين الشائعة
يمكن أن يحدث RST:
- مباشرة بعد SYN.
- بعد SYN-ACK.
- بعد ClientHello.
- بعد طلب HTTP.
- أثناء مهلة الخمول.
- بعد بيانات البروتوكول غير صالحة.
- عندما يقوم أحد التطبيقات بإغلاق مأخذ توصيل يحتوي على بيانات غير مقروءة.
- عندما يرفض جدار الحماية سياسة ما.
- عندما لا يكون لموازن التحميل واجهة خلفية سليمة.
- عندما تتعطل عملية الخادم أو ترفض الحالة.
التوقيت يخبرك أين تبحث.
الذي أرسل RST
حدد أولاً عنوان IP المصدر، والمنفذ المصدر، وعنوان IP الوجهة، ومنفذ الوجهة لحزمة إعادة التعيين. إذا أرسل عنوان IP الخاص بالخادم RST، فهذا يعني أن جانب الخادم أو شيء ينتحل شخصية هذا الجانب قد أنهاه. إذا أرسل عنوان IP الخاص بالعميل RST، فهذا يعني أنهائه من جانب العميل. إذا كان سلوك TTL أو MAC أو المسار يشير إلى صندوق متوسط، فقد يتم إدخال إعادة التعيين.
لا تعتمد فقط على صياغة التطبيق. قد يتم الإبلاغ عن "إعادة التعيين بواسطة النظير" من قبل الجانب الذي تلقى RST.
إعادة الضبط بعد SYN
غالبًا ما يعني RST بعد SYN أن المنفذ مغلق أو أن السياسة ترفض الاتصال. إذا استقبل SYN RST على الفور، فلن يصل التطبيق مطلقًا إلى TLS أو HTTP.
بحث:
- SYN -> RST، ACK
- لا يوجد خادم مرحبا
- لا توجد بيانات التطبيق
- سلوك متسق عبر المحاولات
هذا ليس فشلًا في الشهادة أو خطأ HTTP؛ إنه فشل في إمكانية الوصول إلى TCP/حالة الخدمة.
إعادة التعيين أثناء TLS
يمكن أن يكون سبب RST بعد ClientHello هو منفذ خاطئ، أو TLS غير مدعوم، أو عدم تطابق SNI، أو سياسة الصندوق الأوسط، أو رفض الخادم. احتفظ ببيانات تعريف DNS وClientHello حتى تتمكن من رؤية اسم المضيف وإصدارات ALPN وTLS والتوقيت.
إذا وصلت إعادة التعيين بعد تنبيه TLS، يكون التنبيه أكثر إفادة من إعادة التعيين. إذا لم يكن هناك تنبيه، فقد تكون إعادة التعيين على مستوى أقل أو تعتمد على السياسة.
إعادة تعيين بعد الطلب
غالبًا ما يعني RST بعد طلب HTTP أو استعلام قاعدة البيانات أو أمر البروتوكول أن التطبيق مفهوم بما يكفي لرفض الطلب أو تعطله. يمكن أن يعني أيضًا إغلاق الوكيل نظرًا لعدم توفر المنبع.
ربط:
- آخر وحدات بايت للتطبيق تم إرسالها.
- استجابة الخادم أو عدم الاستجابة.
- وقت الخمول قبل إعادة التعيين.
- سجلات الواجهة الخلفية/موازنة التحميل.
- ما إذا كانت إعادة التعيين ستتم فقط لأحجام طلب معينة.
Checklist
استخدم سير العمل هذا:
- حدد أول RST في المحادثة.
- تحديد من أرسلها.
- فحص ما حدث قبل ذلك مباشرة.
- التحقق من اكتمال مصافحة TCP.
- تحقق مما إذا كان TLS قد بدأ أو اكتمل.
- التحقق من إرسال بيانات التطبيق.
- تحقق من توقيت مهلة الخمول.
- قارن أدلة TTL/MAC/المسار لحقن الصندوق الأوسط.
- احتفظ بـ DNS وTCP وTLS ووحدات بايت التطبيق حول عملية إعادة التعيين.
- استخدم سجلات الخادم/موازن التحميل لتأكيد الإسناد.
التشخيص النهائي
TCP RST عبارة عن إحباط اتصال، لكن السبب يعتمد على التوقيت والمرسل. يمكن لـ pcap التمييز بين المنفذ المغلق ورفض جدار الحماية ورفض TLS وإغلاق التطبيق ومهلة الخمول وفشل موازن التحميل وإعادة تعيين الصندوق الأوسط.
تساعد جراحة PCAP في الحفاظ على تسلسل الحزمة الذي يجيب على السؤال الأكثر أهمية: من الذي أعاد ضبط الاتصال، وماذا حدث قبل ذلك مباشرة؟