حالة NEW في conntrack على حزمة ACK: ما الذي لا تثبته

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

ابدأ من الحزمة لا من الحكم

افصل المشاهدات قبل تفسيرها. أعلام TCP تصف هذه الحزمة، وحالة المتتبّع تصف ما كان يعرفه عند ذلك الـhook، أما التقاطك فيصف النافذة التي سجلتها فقط.

خلط هذه الثلاثة هو ما يجعل حزمة ACK تتحول إلى «مزوّد الخدمة سمح لأحد بالدخول».

ما تعنيه NEW فعلاً عند الـhook

مطابقة conntrack في iptables توثّق NEW على أنها حزمة تبدأ اتصالاً، أو حزمة مرتبطة باتصال لم يشهد مروراً في الاتجاهين بعد. أما ESTABLISHED فتعني أن المتتبّع رأى حزماً في الاتجاهين. ولا شيء في أي من التعريفين يقول إن الحزمة كانت SYN، ولا يقول إنها وصلت بلا تاريخ.

المتتبّع الذي يبدأ مراقبة تدفّق من منتصفه يصنّف الحزمة التالية وفق ما يعرفه، وقد لا يعرف شيئاً. هذا كلام عن ذاكرة المتتبّع لا عن نيّة المضيف البعيد.

التتبّع المرن يفسّر معظم مفاجآت ACK

يوثّق الـkernel nf_conntrack_tcp_loose، وهو يسمح للمتتبّع بالتقاط اتصالات TCP لم يرَ بدايتها. وبالقيمة الافتراضية لهذا الإعداد يمكن قبول حزمة ACK من منتصف التدفّق كتدفّق قائم. أوقف هذا الإعداد، فتصبح الحزمة نفسها أقرب إلى أن تُصنَّف INVALID بدل NEW. وكلا النتيجتين تصف قواعد المتتبّع لا تاريخ التطبيق.

لذا تحقّق من ذلك الإعداد قبل أن تبني نظرية على العلامة.

استبعد الأسباب المملة بهذا الترتيب

معظم أحداث NEW على ACK التي تتبعتُها انتهت إلى واحد من هؤلاء، وكلها رخيصة الفحص:

• مُسح جدول conntrack، أو أُعيد تشغيل المتتبّع.
• أُعيد تشغيل المضيف، أو انتقل التدفّق إلى namespace أو جهاز آخر.
• التوجيه غير المتماثل أخرج حزمة SYN عبر مسار لا تلتقطه.
• أعاد NAT كتابة الـtuple، فلم تعد المدخلة تطابق ما قرأته.
• بدأ الالتقاط متأخراً ولم يرَ البداية أبداً.

كل واحد من هؤلاء يزيل الحزم الأسبق من مجال رؤية المتتبّع ويُبقي الحزم اللاحقة سليمة. وإعادة التشغيل أو مسح الجدول أسهل ما يُثبت من الـuptime والسجلات. والتوجيه غير المتماثل يظهر كالتقاط أحادي الاتجاه. أما NAT فهو الماكر، لأن الـtuple الذي خزّنه المتتبّع ليس الـtuple المطبوع في السجل.

اكتب أي هذه الأسباب استبعدته، وكيف، قبل أن تمضي.

اقرأ الـtuple والواجهة والـhook

مدخلة conntrack مفتاحها العناوين والمنافذ والبروتوكول، لذا أي ترجمة تغيّر المدخلة المطابقة. وسجّل الواجهة والـhook أيضاً، لأن حزمة تُرى على واجهة خاطئة أو بعد سلسلة مختلفة تقول لك إن المسار ليس كما في الرسم. وحين يتعلق الحدث بـVPN، حدّد ما إذا كنت تنظر إلى الحزمة الداخلية أم إلى الحامل الخارجي. ثم قارن بما سجّلته البوابة لنفس الـtuple الخماسي.

رؤيتان لتدفّق واحد تختلفان أنفع من أي منهما منفردة.

متى يستحق التصعيد

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

ثم رُمّ الفجوة في الرؤية التي جعلت حزمة واحدة تبدو كجلسة كاملة.