چرا tcpdump متن ساده IPsec را فقط در یک جهت نشان می‌دهد

tcpdump را روی رابط خارجی یک دروازه IPsec لینوکس اجرا می‌کنید و همزمان دو چیز می‌بینید: فریم‌های 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 ترافیکی را پوشش می‌دهد که خود دروازه تولید می‌کند؛ عبور از یک مشتری LAN به‌جایش از زنجیره 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 است. اول مسیر را مشخص کنید، سپس نقطه‌ای را برگزینید که به پرسش پاسخ می‌دهد، و انتظار داشته باشید دو جهت فقط وقتی متفاوت به نظر برسند که به سمت نادرست دگرگونی نگاه می‌کنید.