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

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

شمارنده‌ها حجم را توصیف می‌کنند، نه جهت خرابی را

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

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

انتخاب همتا یا مسیر پاسخ: دو توضیح

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

ObservationPoints to
No handshake while transmit climbsPeer selection or endpoint
Handshake current, request visible on the serverReply path or far-side route
Request never visible on the serverAllowed prefixes or local route
Both packets visible, nothing reaches the clientReturn filter or translation

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

دو سطر از این چهار سطر روی کلاینت و دو سطر روی سرور درست می‌شوند. دانستن اینکه در کدام جفت هستید بیشترِ کار است.

پاسخ‌ها کجا ناپدید می‌شوند

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

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

یک مقصد را سرتاسر آزمایش کنید

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

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

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

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

مقالات مرتبط