لماذا يُظهر tcpdump نص IPsec الصريح في اتجاه واحد فقط

تشغل tcpdump على الواجهة الخارجية لبوابة IPsec على Linux وترى أمرين في آن واحد: إطارات ESP الواردة، وبعدها مباشرة الحزم الداخلية المفكوكة التشفير. وفي الاتجاه الصادر لا يظهر سوى ESP. والاستنتاج الطبيعي أن الردود لا ترسل، أو أن IPsec يشفّر اتجاها واحدا وينسى الآخر. لا شيء من ذلك صحيح.

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

موضع الالتقاط هو الذي يحدد ما تراه

على واجهة عادية، يجلس مقبس AF_PACKET قرب طبقة الجهاز. تمر الحزم الخارجة من المضيف أولا عبر معالجة خرج IPsec، التي تحوّل مقطع TCP داخليا إلى مخطط ESP أو مخطط UDP-4500، ولا تصل إلى تلك الطبقة إلا بعد ذلك. أما الحزم الواردة فتُنسخ إلى المقبس وهي تخرج من السلك، ولا تزال مشفرة، ويصبح الناتج المفكوك التشفير مرئيا لاحقا حين يسلّمه المكدس محليا أو يمرره.

يفسّر هذا الترتيب عدم التماثل تفسيرا كاملا. وهو ليس دليلا على الاتجاه أو السياسة أو سلوك التطبيق، ومعاملته كذلك تدفع الناس إلى مطاردة رد أُرسل بشكل صحيح طوال الوقت. وهو أحد الأمثلة النادرة في الشبكات حيث الأداة، لا الشبكة، هي التي تخلق الشذوذ.

طابِق المرشح مع الطبقة التي تعنيها

تعبير مثل tcp port 443 يختار اتصال TCP داخليا. في الاتجاه الصادر، يكون ذلك الاتصال قد أصبح ESP بحلول وقت الرجوع إلى المقبس، فلا يطابق المرشح شيئا. إذا أردت عدّ حركة المرور المحمية، فاستخدم المرشح على الشكل الخارجي بدلا من ذلك: البروتوكول 50 لـ ESP الخام، أو منفذ UDP 4500 عند استخدام تجاوز NAT. كلا المرشحين ينتج عددا للحزم يمكن مقارنته بين الطرفين، وهو عادة سبب العد أصلًا. ولا يخبرك أي منهما ما إذا كان الطلب الداخلي قد لقي ردًا.

لا تتعامل مع عدد UDP 4500 على أنه عدد حزم ESP. يستخدم IKE أيضا ذلك المنفذ لإشارات استمرار NAT-T وللتبادل المغلف، لذا يتضمن الرقم حركة مرور ليست البيانات التي أردت قياسها. ويحتاج تبادل IKE الأولي على UDP 500 إلى مرشحه الخاص إذا كان ذلك هو السؤال. والرقم الذي يخلط حركة التحكم بالبيانات يجعل أيضا أي تقدير للنطاق الترددي خاطئا بهامش غير معروف. أعداد منفصلة تجيب عن أسئلة منفصلة.

دوّن المرشح بجانب السؤال الذي يجيب عنه. فسؤال «كم من ESP غادر الصندوق» وسؤال «هل غادر طلب الويب الصندوق» قياسان مختلفان بمرشحين مختلفين، والتقاط واحد لا يمكنه حسم الاثنين. وبدون تلك الملاحظة، سيقارن شخصان رقمين لم يكونا يعدان الشيء نفسه يوما.

راقب قبل التحويل، لا بعده

إذا كنت بحاجة إلى رؤية النص الصريح الصادر، فحرّك نقطة المراقبة إلى وقت أبكر، قبل معالجة خرج IPsec. يمنحك NFLOG خطافا في Netfilter حيث يمكن لقاعدة أن تنسخ حزما مختارة إلى مقبس في مساحة المستخدم، يستطيع tcpdump قراءته. ويوثّق دليل تفريغ حركة المرور في strongSwan هذا الأسلوب لهذا السبب تحديدا.

تحدّ القاعدة المطابقة لأي سياسة من تطبيقها على حركة المرور التي على وشك دخول نفق. و -m policy --pol ipsec --dir out هو ما يجعل القاعدة محددة بدلا من تسجيل كل حزمة يرسلها الصندوق. ثم اقرأ مجموعة السجل بعملية التقاط محدودة: عدد لقطات صغير وحد للحجم يمنعان التشخيص من أن يصبح أرشيفا لحركة المرور. كما أن الالتقاط المحدود أسهل في تسليمه إلى مراجع دون جرّ حمولة غير ذات صلة معه. قرّر العدد قبل أن تبدأ، لا بعد أن ترى كم وصل.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

اختر الخطاف ليطابق التدفق. OUTPUT يغطي حركة المرور التي يولّدها الجهاز نفسه؛ أما العبور من عميل في شبكة محلية فيمر عبر سلسلة FORWARD بدلا من ذلك، ولن تراه قاعدة على OUTPUT أبدا. العنوان والمنفذ أعلاه عنصران نائبان عن وجهة اختبار معتمدة.

ما الذي تثبته المراقبة

NFLOG هدف تسجيل، وليس قرار قبول. ظهور حزمة هناك يُظهر أنها وصلت إلى الخطاف وطابقت القاعدة. ولا يُظهر أن مرشحا لاحقا سمح بها، أو أن الجهاز أرسلها، أو أن الطرف الآخر استقبل أي شيء.

السجل الفارغ غامض بالقدر نفسه. تحقق من عداد حزم القاعدة، وأكّد الاتجاه، وأكّد أن التدفق طابق فعلا سياسة IPsec، وأكّد الوجهة. ولا يحوّل المراقبة إلى استنتاج إلا عداد مطابق على الطرفين. ثم قارن عدادات ارتباط الأمان على الطرفين للمحاولة المضبوطة نفسها، لأن عدادات SA هي السجل الموثوق لما حُمي وأُرسل.

فخ آخر: «النص الصريح» في هذا السياق يعني خارج طبقة تشفير IPsec. فجلسة HTTPS الداخلية لا تزال لها TLS الخاصة بها. والتقاط الحزمة المفكوكة التشفير لا يفك تشفير TLS الخاص بالتطبيق، ورؤية HTTP مقروءا هناك تعني أن التطبيق لم يستخدم HTTPS أصلًا.

نظف وقارن الطرفين

أزل القاعدة نفسها التي أدرجتها، من مالكها، بمجرد انتهاء المراقبة. فترك قاعدة تسجيل في المكان يكلّف CPU على كل حزمة مطابقة ويخلق بهدوء مشكلة احتفاظ بالبيانات. احذفها بتكرار القاعدة مع -D بدلا من تفريغ سلسلة لا تملكها.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

إذا كان النشر يستخدم IPsec في مساحة المستخدم، أو واجهة XFRM، أو تفريغا عتاديا، فإن نقاط المراقبة تتحرك وقد لا تنطبق هذه الوصفة إطلاقا. ومع libipsec، فإن المكان الموثق لمراقبة حركة المرور الداخلية هو جهاز TUN. حدّد المسار أولا، ثم اختر النقطة التي تجيب عن السؤال، وتوقع أن يبدو الاتجاهان مختلفين فقط عندما تنظر إلى الجانب الخطأ من التحويل.