ike-scan هیچ پاسخی از یک دروازه IPsec سالم نمی‌گیرد

دروازه هر روز به تلفن‌ها و لپ‌تاپ‌ها خدمت می‌کند، با این حال ike-scan گزارش می‌دهد که هیچ میزبانی پاسخ نداده است. این خروجی مانند مدرکی است که IPsec روی دستگاه وجود ندارد. معمولاً یعنی دستگاه هر پیشنهاد موجود در کاوش را رد کرده و تصمیم گرفته هیچ چیز پاسخ ندهد. سکوت هم یک پاسخ است، و کم‌اطلاع‌ترین پاسخی است که ابزار می‌تواند به شما بدهد.

سه پرسش جداگانه را بررسی کنید: آیا بسته رسید، آیا پیشنهادی مطابقت داشت، و آیا چیز دیگری همتا را رد کرد؟

گام 1: پیشنهادی را که ابزار می‌فرستد بخوانید

حالت اصلی با یک بار SA آغاز می‌شود که تبدیل‌های مورد پذیرش آغازگر را فهرست می‌کند، و ike-scan آن فهرست را از یک مجموعه پیش‌فرض کامپایل‌شده پر می‌کند. مجموعه پیش‌فرض عمداً قدیمی است: DES و 3DES برای رمزنگاری، MD5 و SHA1 برای درهم‌سازی، گروه‌های 1 و 2 برای تبادل کلید، کلیدهای از پیش تقسیم‌شده برای احراز هویت. بدون AES، بدون SHA-2، بدون گروه 14. دروازه‌ای که برای AES-256 با SHA-256 و modp2048 پیکربندی شده هیچ چیز مشترکی با آن ندارد.

برخی پیاده‌سازی‌ها به کاوش ناسازگار با اعلان NO-PROPOSAL-CHOSEN پاسخ می‌دهند. دیگران به‌سادگی آن را دور می‌ریزند، که در دستگاه‌هایی که همتاهای ناشناس را نویز می‌دانند رایج است. در هر حال پویش چیزی چاپ نمی‌کند، و آن هیچ دقیقاً همان چیزی است که یک UDP 500 فیلترشده از بیرون به نظر می‌رسد، چنانکه مستندات پروژه ike-scan درباره مجموعه پیش‌فرض روشن می‌سازد.

گام 2: یک پیشنهاد مدرن ارائه دهید

مجموعه پیش‌فرض را با --trans جایگزین کنید. شکل ویژگی شماره‌های ویژگی IKE را مستقیماً می‌گیرد: 1 برای رمزنگاری، 2 برای درهم‌سازی، 3 برای احراز هویت، 4 برای گروه، و 14 برای طول کلید وقتی الگوریتم یکی می‌گیرد. خروجی خطی است که می‌توانید در بازبینی تغییرات با صدای بلند بخوانید.

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

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

یک پیشنهاد برای هر بسته هنگام شمارش کند است، پس مقادیر محتمل را مرور کنید: رمزنگاری 5، 7/128، 7/192، 7/256؛ درهم‌سازی 1، 2، 5، 6، 7؛ گروه‌ها 1، 2، 5، 14، 15، 19، 20، 21؛ احراز هویت 1 برای کلید از پیش تقسیم‌شده و 3 برای امضاهای RSA. هر فرمان را پیش از اجرا چاپ کنید تا رونوشت نشان دهد چه چیزی و به چه ترتیبی ارائه شده است.

گام 3: پاسخ را تفسیر کنید

یک پاسخ دقیقاً دو چیز را اثبات می‌کند: یک پاسخ‌دهنده IKE در آن نشانی قابل دسترسی است، و یک پیشنهاد ارائه‌شده قابل قبول بود. درباره کلید از پیش تقسیم‌شده، لایه L2TP یا وجود حساب کاربری چیزی نمی‌گوید. پویش موفق کاملاً با شکست هر مرحله بعدی سازگار است.

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

گام 4: سکوت را تفسیر کنید

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

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

گام 5: آنچه اثبات کردید را ثبت کنید

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

کاوشی که هرگز پاسخ نداد باز هم چیزی پاسخ داده است: نشان می‌دهد این دستگاه کدام پیشنهادها را آماده بحث است و کدام‌ها را ترجیح می‌دهد روی زمین بیندازد.