چگونه یک تبادل تازه IKE_SA_INIT را در یک فایل ضبط بخوانیم

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

نخست، تأیید کنید که ضبط از ابتدا شروع شده است

ضبطی که پس از بالا آمدن تونل آغاز شده باشد جریان داده قالب‌بندی‌شده و keepaliveهای دوره‌ای را در بر می‌گیرد و هر دو یا رمزنگاری‌شده‌اند یا تقریباً خالی. کارخواه را دوباره راه‌اندازی کنید و خودِ تلاش را ضبط کنید، یا عمداً در حین اجرای ضبط یک اتصال تازه ایجاد کنید. اگر نمی‌توانید تلاش تازه‌ای پدید آورید، آن را در یادداشت‌های خود بنویسید، زیرا هیچ رمزگشایی‌ای آغازی را که هرگز ضبط نکرده‌اید بازنمی‌گرداند.

ضبط را به دو نقطه پایانی و به UDP 500 و 4500 محدود کنید تا پرونده به‌اندازه کافی کوچک بماند. روی میزبان پرترافیک، ضبط بی‌فیلتر مذاکره را زیر ترافیک بی‌ربط دفن می‌کند.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

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

دوم، سرایند را پیش از بارها بخوانید

سرایند IKE شاخص‌های پارامتر امنیتی، نوع تبادل و شناسه پیام را حمل می‌کند و در مذاکره تازه این مقادیر متمایزند. آغازگر یک SPI ناصفر می‌سازد، درخواست نخستین SPI پاسخ‌دهنده صفر را حمل می‌کند چون هنوز پاسخی دیده نشده است، نوع تبادل IKE_SA_INIT است و شناسه پیام صفر است. هر چیز دیگری به مرحله بعدی همان مذاکره یا به تلاشی کاملاً متفاوت تعلق دارد.

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

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

سوم، درخواست را با پاسخش تطبیق دهید

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

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

جهت هم مهم است. درخواست بی‌پاسخ و پاسخی که هرگز به کارخواه نمی‌رسد دو ایراد متفاوت‌اند و تنها دومی مانند یک وقفه از سمت کارخواه به نظر می‌رسد.

چهارم، IKE را از هر چیز دیگری روی 4500 جدا کنید

درگاه 4500 سه چیز را حمل می‌کند که در نمای خلاصه یکسان به نظر می‌رسند: IKE پشت نشانگر non-ESP صفر چهاربایتی، ESP قالب‌بندی‌شده که جای نشانگرش SPI ناصفر دارد، و keepaliveهای کوتاه. همان نشانگر است که IKE را از ESP قالبی جدا می‌کند، پس آن بایت‌ها را پیش از نامیدن ترافیک به IKE بخوانید. برچسب ضبطی که 4500 را می‌خواند شماره درگاه است، نه پروتکل.

ESP قالبی باری رمزنگاری‌شده است که بدون کلید نمی‌توانید تفسیرش کنید و حضورش می‌تواند نشانه تونلی کارکننده باشد نه ایراد.

هر دو درگاه را برای همان تلاش بپایید، زیرا IKE می‌تواند پس از تشخیص NAT به 4500 جابه‌جا شود هرچند روی 500 باز شده باشد. ردپایی که تنها بر 500 فیلتر شده دقیقاً وقتی خاموش به نظر می‌رسد که مذاکره کامیاب شده و جابه‌جا شده است. فیلتر را گسترده کنید و همان پنجره زمانی را دوباره بخوانید پیش از آنکه از نبود چیزی نتیجه‌ای بگیرید.

سکوت در یک نقطه مشاهده به چه معناست

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

یک ICMP unreachable مربوطه شاهدی می‌افزاید، اما بسته نقل‌شده درونش را بخوانید و نشانی دستگاهی که آن را فرستاده یادداشت کنید.

رد شدن از سوی مسیریاب رویدادی متفاوت از خطای احرازشده بازگشتی از طرف مقابل است و تنها دومی اثبات می‌کند سرویس زنده است. همان تلاش را با گزارش‌های سرور یا مشاهده‌ای تأییدشده پیوند دهید تا بدانید درخواست رسید و پاسخی بیرون رفت. ضبط‌ها را محدود و خصوصی نگه دارید، زیرا میدان‌های خواندنی دست‌دادن بقیه پرونده را بی‌خطر نمی‌کند. نتیجه‌ای که ارزش دارد یک جفت درخواست و پاسخ تطبیق‌شده است، یا شکافی مستند با نقطه مشاهده‌ای نام‌برده.