WireGuard آخرین دست‌دادن را نشان نمی‌دهد: ابتدا چه چیزی را بررسی کنید

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

آزمون یک بستهٔ مجاز به سمت مقصدی است که همتا باید حمل کند. هر چیز دیگری در آن صفحهٔ وضعیت نیت را توصیف می‌کند نه فعالیت.

رابط بی‌کار چیزی برای گزارش ندارد

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

اگر شمارنده‌ها در هر دو طرف صفر باشند، مشکل بالادست تونل است. هیچ چیز به رابط نرسید تا چیزی را آغاز کند.

ترافیکی را تحریک کنید که همتا مجاز به حمل آن است

نشانی‌ای درون پیشوندهای مجاز همتا، روی ماشین محلی، انتخاب کنید و تأیید کنید که جدول مسیریابی آن را از رابط می‌فرستد. مقصدی بیرون از آن پیشوندها یک درخواست مسیریابی‌شدهٔ عادی بدون هیچ دخالت WireGuard تولید می‌کند. از سرویسی استفاده کنید که سریع پاسخ می‌دهد، مانند ping یا یک اتصال کوتاه TCP، تا تلاش آغاز و پایان دیدنی داشته باشد. سپس به‌جای تماشای صفحه و انتظار، خط دست‌دادن را دوباره بخوانید.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

پرس‌وجوی مسیر مهم‌تر از ping است. اگر رابط فیزیکی را نام ببرد، بسته هرگز وارد تونل نشده و دست‌دادن خالی پاسخ مسیریابی است نه رمزنگاری. پیش از اشکال‌زدایی همتا مسیر را درست کنید.

جفت کلید و نقطهٔ پایانی را مقایسه کنید

وقتی ترافیک واقعاً پیشنهاد شد، هویت بررسی بعدی است. کلید خصوصی محلی باید با کلید عمومی‌ای که طرف مقابل مجاز می‌داند مطابقت داشته باشد، کلید عمومی دورِ پیکربندی‌شده باید همتای موردنظر را شناسایی کند، و هر کلید از پیش مبادله‌شده باید در دو طرف یکسان باشد. تفاوت یک نویسه در کلید base64 همتایی می‌سازد که پیکربندی‌شده به نظر می‌رسد و هرگز تبادلی را کامل نمی‌کند. به‌جای بازتولید کلیدها با سابقهٔ تأمین مقایسه کنید، زیرا کلید تازه هر همتایی را که به کلید قدیمی اعتماد داشت بی‌اعتبار می‌کند.

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

مسیر بیرونی UDP را زیر نظر بگیرید

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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