گیر کردن WireGuard: محدودیت MTU یا قاعدهٔ ارسال مفقود؟

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

دو شکست، دو شکل متفاوت

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

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

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

پیش از کوچک کردن هر چیزی ارسال را کنار بگذارید

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

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

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

اندازه بگیرید که شکست از کجا شروع می‌شود

نخست وضعیت ارسال و قاعده‌های فیلتر را بخوانید. این‌ها بررسی‌های فقط خواندنی هستند و به پرسش ارزان پاسخ می‌دهند:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

سپس اندازه‌ها را با بیت don’t-fragment، از کلاینت، به سوی میزبان فراتر از دروازه بیازمایید:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

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

لایه‌ای را که اثبات کردید درست کنید

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

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

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