اسکن UDP می‌گوید فیلترشده: آیا همتای WireGuard شما واقعاً از کار افتاده است؟

اسکنرها برای یک پورت UDP «باز» یا «فیلترشده» چاپ می‌کنند و نتیجه‌گیری معمولاً در چند ثانیه می‌آید: تونل خراب است. ممکن است چنین باشد، اما اسکن این را ثابت نکرد. UDP هیچ دست‌دادن اتصالی حمل نمی‌کند و WireGuard به چیزی که نتواند احراز هویت کند پاسخ نمی‌دهد، بنابراین سکوت پاسخ مورد انتظار به بیشتر کاوش‌ها است.

در عوض از سمت کارخواه به بیرون کار کنید و اسکن را یک نقطه داده ضعیف در میان چندین نقطه بدانید.

اسکنر چه چیزی را می‌تواند و چه چیزی را نمی‌تواند ببیند

اسکنر UDP یک بار ترافیک می‌فرستد و منتظر می‌ماند. اگر ICMP port-unreachable برگردد، می‌تواند پورت را بسته اعلام کند. اگر چیزی برنگردد، نتیجه به‌حکم طراحی مبهم است: مسیر فیلترشده، میزبان غایب و سرویس در حال اجرایی که بار را نادیده گرفته است، همگی همان سکوت را تولید می‌کنند. سه وضعیت متفاوت، یک رشته خروجی.

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

آزمون TCP روی همان شماره پورت هیچ چیز مرتبطی را بررسی نمی‌کند. این آزمون یک شنونده دیگر را که ممکن است وجود نداشته باشد درگیر می‌کند و رد شدن آن هیچ چیزی درباره UDP نمی‌گوید.

بنابراین وضعیت‌های باز فیلترشده، عدم قطعیت اسکنر را دقیق‌تر از سرور شما توصیف می‌کنند.

کارخواه واقعی را از پروفایل به سمت داخل طی کنید

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

سپس در حالی که یک تلاش مجاز رخ می‌دهد سمت سرور را ببینید، به‌جای اجرای یک اسکن جداگانه از مکان سوم:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

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

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

وقتی سرور را مدیریت می‌کنید همان‌جا همبستگی برقرار کنید

تأیید کنید که شنونده وجود دارد و فایروال ارائه‌دهنده پورت UDP را مجاز می‌کند. قاعده فایروال میزبان و گروه امنیتی ابری دو دروازه مستقل هستند و هر کدام می‌توانند بسته‌ای را که دیگری مجاز کرده دور بیندازند. هر دو را با پورت واقعی در پیکربندی بسنجید، نه با پورتی که به یاد دارید.

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

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

خواندن صادقانه نتیجه اسکن

اسکن روشی ارزان برای بررسی وجود میزبان و اینکه پورت به‌طور آشکار توسط دستگاهی میانی مسدود نشده است. این اثبات دسترسی‌پذیری برای یک پروتکل احراز هویت‌شده نیست و قطعاً آزمون پیکربندی نیست.

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

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