قد تظهر واحدة أو أكثر من هذه الأعراض:
حالات انقطاع متقطعة في الاتصال للتطبيقات التي تتجاوز مجموعة FTD
يفشل تأكيد اتصال TCP الثلاثي أثناء محاولات الاتصال.
يرسل العميل حزمة SYN، ولكنه لا يتلقى إستجابة SYN-ACK المتوقعة.
يرسل العميل حزمة RST بعد النظام الأولي.
شوهد أول مرة في برنامج Secure Firewall Threat Defense 7.4 — يمكن أن تتأثر نسخ أخرى أيضا
تكوين نظام المجموعة
موازن التحميل في مسار الشبكة — هذا إختياري
inline_image_0.png
لحل المشكلة الجذرية، تحتاج إلى أخذ لقطات متزامنة في هذه النقاط:
FW1 داخلي قارن (مع reinject-hide)
FW1 الواجهة الخارجية (مع reinject-hide)
واجهة مجموعة FW1 (CCL)
واجهة FW2 الداخلية (مع reinject-hide)
الواجهة الخارجية FW2 (with reinject-hide)
واجهة نظام المجموعة ل FW2 (CCL)
العميل (أو أقرب ما يمكن إلى العميل)
الخادم (أو أقرب ما يمكن إلى الخادم)
للحصول على تفاصيل حول كيفية تكوين فحص الالتقاط: كيفية تمكين مجموعات نظام المجموعة.
تكشف عمليات الالتقاط التي تم التقاطها على جدران الحماية إلى جانب العميل والخادم عن هذه الطوبولوجيا:
inline_image_0.png
1. يرسل العميل TCP syn. تصل الحزمة إلى موازن التحميل (LB) ويتم إرسالها إلى FW1.
2. يستلم FW1 حزمة TCP syn ويصبح مالك التدفق.
3. يقوم FW1 بإبلاغ المدير (FW2) عن مالك التدفق من خلال إرسال رسالة نظام مجموعة خاصة (CLU add).
4. يرسل FW1 نظام TCP إلى الخادم الوجهة.
ملاحظة: تحدث الخطوات 3 و 4 بدون ترتيب محدد.
5. يرد الخادم مع SYN/ACK. في هذه الحالة، لدينا تدفق غير متماثل منذ أن تم إرسال SYN/ACK إلى FW2 بسبب خوارزمية موازنة حمل قناة المنفذ.
6. يصل SYN/ACK إلى FW2 قبل إضافة رسالة CLU. هذا شرط عرقي وبيئي محض (مثل زمن الوصول في CCL). وبما أن FW2 لا يعرف من هو مالك التدفق، يتم إسقاط SYN/ACK.
7. يتم إرسال TCP RST إلى الخادم.
8. تصل رسالة إضافة clu إلى FW2.
9. يرسل العميل حزمة TCP syn. تتم إعادة توجيه حزمة TCP syn إلى الخادم الوجهة.
10. في LB، ينتهي اتصال TCP الخاص بالتدفق المحدد.
11. يرد الخادم مع SYN/ACK (إعادة إرسال TCP). تصل حزمة SYN/ACK إلى FW2. هذه المرة، يعرف FW2 عن مالك التدفق لأنه حصل على رسالة إضافة CLU ويتم إعادة توجيه SYN/ACK إلى مالك التدفق عبر CCL. يتم إرسال SYN/ACK إلى العميل.
12 - ولا تعرف الشركة الليبرية عن هذا التدفق وتلقي نظام SYN/ACK، ومن ثم، لا يصل النظام/ACK أبدا إلى العميل.
13. LB واحد أو أكثر من حزم TCP RST.
في هذه المخرجات، تم تجميع الالتقاط من جدار الحماية على واجهات CCL والواجهات التي تواجه الخادم:
· على CCL يكون الالتقاط على منفذ UDP 4193.
· على واجهات البيانات، يطابق الالتقاط حركة مرور TCP بين نقاط النهاية باستخدام خيار الإدراج-hide. السبب هو أننا نريد أن نرى أين تصل الحزم بالفعل.
· عنوان IP 192.0.2.65 = العميل
· عنوان IP 192.0.2.6 = الخادم
الخطوة 1: أستخدم هذا الأمر على جهاز جدار الحماية الذي يحصل على SYN/ACK لمعرفة وقت وصول رسالة إضافة CLU. في إخراج واجهة سطر الأوامر (CLI) يتم عرض الرسالة ك إضافة تدفق.
firepower# show capture CCL decode
3 packets captured
1: 08:14:20.630521 127.2.1.1.51475 > 127.2.2.1.4193: udp 820
Cluster ASP message: sender: 1, receiver: 0
Add flow: owner 1, director 0, backup 0,
ifc_in INSIDE(7020a7), ifc_out INSIDE(7020a7)
TCP src 192.0.2.65/37468, dest 192.0.2.6/80
الخطوة 2: تتبع حزمة SYN/ACK والتركيز على الطابع الزمني ونتيجة التتبع:
firepower# show capture CAPI packet-number 1 trace
13 packets captured
1: 08:14:20.628690 802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2524735158:2524735158(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611712900 970937593,nop,wscale 7>
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 1708 ns
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 1708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Elapsed time: 13664 ns
Config:
Additional Information:
Found next-hop 192.168.200.140 using egress ifc INSIDE(vrfid:0)
Phase: 4
Type: CLUSTER-EVENT
Subtype:
Result: ALLOW
Elapsed time: 16104 ns
Config:
Additional Information:
Input interface: 'INSIDE'
Flow type: NO FLOW
I (0) am becoming owner
Phase: 5
Type: OBJECT_GROUP_SEARCH
Subtype:
Result: ALLOW
Elapsed time: 19520 ns
Config:
Additional Information:
Source object-group match count: 0
Source NSG match count: 0
Destination NSG match count: 0
Classify table lookup count: 1
Total lookup count: 1
Duplicate key pair count: 0
Classify table match count: 4
Phase: 6
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 366 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268436480
access-list CSM_FW_ACL_ remark rule-id 268436480: ACCESS POLICY: mzafeiro_empty - Default
access-list CSM_FW_ACL_ remark rule-id 268436480: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
Phase: 7
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 366 ns
Config:
class-map tcp
match access-list tcp
policy-map global_policy
class tcp
set connection conn-max 0 embryonic-conn-max 0 random-sequence-number disable syn-cookie-mss 1380
service-policy global_policy global
Additional Information:
Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 366 ns
Config:
Additional Information:
Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 366 ns
Config:
Additional Information:
Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 54168 ns
Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7459 flow (NA)/NA
· وصلت رسالة إضافة تدفق إلى 08:14:20.630521 بينما كان SYN/ACK ~2 msec سابقا في 08:14:20.628690. هذه هي حالة السباق.
· يتم إسقاط حزمة SYN/ACK بواسطة جدار الحماية لسبب TCP-not-syn ASP. لاحظ أنه في المرحلة 4 حاول جدار الحماية تحديد ما إذا كان هناك مالك تدفق معروف أم لا، وبالتالي، حاول أن يصبح مالك تدفق.
يظهر هذا الإخراج مسارا ل SYN/ACK عندما يعرف جدار الحماية التدفق:
firepower# show capture CAPI packet-number 3 trace
13 packets captured
3: 08:14:21.629560 802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2540375172:2540375172(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611713901 970938595,nop,wscale 7>
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 1708 ns
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 1708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: CLUSTER-EVENT
Subtype:
Result: ALLOW
Elapsed time: 3416 ns
Config:
Additional Information:
Input interface: 'INSIDE'
Flow type: STUB
I (0) have flow, valid owner (1).
Phase: 4
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 7808 ns
Config:
Additional Information:
MAC Access list
Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
Action: allow
Time Taken: 14640 ns
1 packet shown
firepower#
النقطة الأساسية في المرحلة 3. يعرف جدار الحماية أن وحدة نظام المجموعة 1 هي مالك التدفق. يمكنك إستخدام الأمر show cluster info لمعرفة الجهاز الذي هو الوحدة 0 والجهاز الذي هو 1.
س. لماذا نرى مشكلات اتصال TCP المتقطعة؟
أ. بما أن هذه هي حالة عرقية، فإنها تحدث عشوائيا. ويمكن تصوير حالة السباق تبعا لذلك:
inline_image_0.png
س. ما هي الحلول الممكنة لتجنب حالة السباق؟
ج.
الحل 1: تمكين تحويل رقم تسلسل TCP عشوائيا للاستفادة من آلية ملف تعريف إرتباط TCP SYN. في هذه الحالة يتم تنظيم الاتصال وفقا لذلك:
inline_image_1.png
الحل 2: تخلص من عدم التناظر في الشبكة. أولا، تحتاج إلى تحديد سبب عدم التناظر. قد يتطلب ذلك ضبط خوارزمية موازنة حمل قناة المنفذ، وإعادة توصيل كبلات قناة المنفذ بترتيب مختلف، من بين أمور أخرى.
السبب الجذري هو حالة سباق ناجمة عن عدم تناسق نظام المجموعة داخل نشر نظام المجموعة في FTD. تتم معالجة حزم SYN-ACK من الخادم بواسطة عقدة نظام مجموعة FTD مختلفة عن تلك التي عالجت حزمة SYN الأولية، مما يمنع إنشاء جلسة TCP المناسبة.
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
3.0 |
23-Apr-2026
|
التنسيق وعلامات الترقيم. |
2.0 |
15-Apr-2026
|
الصور المضافة |
1.0 |
09-Apr-2026
|
الإصدار الأولي |