چگونه اولین تبادل IKEv2 را در یک ضبط بسته بخوانیم

ضبط‌هایی که در میانهٔ نشست گرفته می‌شوند دلیل معمول شبیه‌بودن یک رد IKEv2 به نویز هستند، چون طرفین هنگام شروع ضبط در حال تازه‌سازی کلیدها یا تبادل بارهای رمزنگاری‌شده‌اند. در عوض از یک تلاش اتصال تازه شروع کنید، تا اولین پیام در فایل همان پیامی باشد که مذاکره را باز می‌کند. ترتیب خواندن زیر همین را فرض می‌کند و نقطه‌ای را نشان می‌دهد که بسته در آن دیگر چیزی دربارهٔ طرف دور اثبات نمی‌کند. رد کردن همین مرحله است که باعث می‌شود یک تونل سالم به‌عنوان درگاه مسدود تشخیص داده شود.

تأیید کنید که به تبادل آغازین نگاه می‌کنید

یک مذاکرهٔ IKEv2 با IKE_SA_INIT آغاز می‌شود، نوع تبادل 34، شناسهٔ پیام 0. آغازگر یک SPI غیرصفر انتخاب می‌کند و SPI پاسخ‌دهنده در آن درخواست نخست صفر و در پاسخ غیرصفر است. این سه واقعیت یک تلاش تازه را از تازه‌سازی کلید یا از پیام IKE_AUTH که تصادفاً بالای یک ضبط قرار گرفته جدا می‌کند.

فیلدهای سرآیند خواندنی‌اند و همچنین بارهای پیشنهاد، تبادل کلید و nonce. خواندنی بودن به معنای احراز‌شده بودن نیست: هیچ‌یک از طرفین در این نقطه هویت خود را اثبات نکرده است و مقدار خصوصی Diffie-Hellman هرگز روی سیم ظاهر نمی‌شود.

فیلدها را به‌صورت جدول چاپ کنید نه با پیمایش در پنل رمزگشایی، چون ارسال‌های تکراری و SPIهای ناهمخوان در ستون‌ها آشکار می‌شوند.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

خروجی را دوبه‌دو بخوانید. درخواستی با شناسهٔ پیام 0 که پاسخی با همان شناسه و SPI پاسخ‌دهندهٔ غیرصفر دنبالش می‌آید یک تبادل است، حتی وقتی سه بار ظاهر می‌شود چون درخواست دوباره فرستاده شده است. سه درخواست یکسان سه ورود نیستند و همین برخورد است که آدم‌ها را به این نتیجه می‌رساند کلاینت در حلقه است، در حالی که فقط شکیباست. بر اساس شناسهٔ پیام و سپس مهر زمان مرتب کنید تا کل گفتگو به فهرستی کوتاه از تلاش‌ها فروبکاهد.

پیش از خواندن یک موفقیت، یک رد را بخوانید

پاسخ لزوماً پیشرفت نیست. پاسخ‌دهنده می‌تواند با یک اعلان cookie پاسخ دهد و انتظار داشته باشد آغازگر دوباره تلاش کند، یا با INVALID_KE_PAYLOAD گروهی را نام ببرد که به‌جای آن می‌پذیرد. هر دو به‌صورت پیام‌های IKE خوش‌ساخت می‌رسند و برای فیلتری که فقط بسته می‌شمارد هر دو شبیه تبادلی تمام‌شده‌اند.

بار اعلان را باز کنید و پیش از هر چیز نوع آن را بخوانید. چالش cookie یعنی پاسخ‌دهنده از خود در برابر نشانی‌های مبدأ جعلی دفاع می‌کند و کلاینت باید با cookie پیوست دوباره بفرستد. گروه نامعتبر یعنی دو پیشنهاد هم‌خوان نیستند و تا وقتی پیکربندی یکی از طرفین تغییر نکند هیچ تعداد تلاش دوباره‌ای آن را عوض نمی‌کند.

تنها IKE_AUTH، یعنی تبادل دوم، هویت رمزنگاری‌شده و بارهای احراز هویت را حمل می‌کند. پس یک IKE_SA_INIT کامل به شما می‌گوید طرفین دربارهٔ الگوریتم‌ها و کلیدهای مشتق‌شده توافق دارند و هیچ چیزی دربارهٔ پذیرفته‌شدن اعتبارنامه‌ها نمی‌گوید. انتظار دو پیام را هم آنجا داشته باشید و انتظار داشته باشید هر دو بدون کلیدهای نشست مات باشند.

درگاه 4500 یک پروتکل نیست

معمولاً UDP 500 تبادل آغازین را حمل می‌کند. پس از اجرای تشخیص NAT، IKE به 4500 می‌رود و پیش از هر پیام یک نشانگر چهاربایتی صفرِ غیرESP می‌گذارد. ESP کپسوله‌شده روی همان درگاه در عوض با یک SPI مربوط به ESP و غیرصفر آغاز می‌شود و یک keepalive یک‌بایتی NAT شکل سومی است که وقتی هیچ چیز دیگری رخ نمی‌دهد ظاهر می‌شود.

فیلتری که فقط با درگاه تطبیق می‌دهد هر سه را با هم قاطی می‌کند، و برای همین جملهٔ "روی 4500 ترافیک هست" چیز کمی را روشن می‌کند. پیش از نتیجه‌گیری دربارهٔ طرف دور، نما را بر اساس پروتکل جدا کنید.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

خاموشی نقطهٔ مشاهده را توصیف می‌کند

درخواست‌های بی‌پاسخ دقیقاً یک چیز را اثبات می‌کنند: در آن نقطهٔ ضبط هیچ پاسخی ظاهر نشد. فیلترکردن، مسیری که پاسخ را جای دیگری می‌فرستد، پاسخ‌دهندهٔ دسترس‌ناپذیر، یا پاسخ‌دهنده‌ای که پیشنهاد را نمی‌پسندد همه یک نتیجهٔ خالی یکسان می‌دهند و یک کاوشگر عمومی UDP آن‌ها را از هم جدا نمی‌کند.

پیام ICMP مبنی بر دسترس‌ناپذیری شاهدی از نوعی دیگر است. بستهٔ نقل‌شده درون آن را بخوانید و مشخص کنید کدام دستگاه آن را فرستاده است، چون رد اداری یک مسیریاب خطای احراز‌شده از طرف دور نیست.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

همان تلاش را با گزارش‌های سمت سرور در جایی که اجازهٔ خواندنشان را دارید تطبیق دهید. آیا درخواست رسید، آیا سرویس پاسخ داد و پاسخ کجا متوقف شد؟ این سه پاسخ شما را به یک مشکل مسیر یا یک مشکل سیاست می‌فرستند و کمتر از تغییر چهارم اعتبارنامه هزینه دارند.