IPIP درون WireGuard: همان 20 بایت اضافه‌ای که کسی در بودجه نگنجاند
IPIP درون WireGuard 20 بایت بیشتر هزینه دارد. بودجه را در لایه درست حساب کنید، پیش از آنکه تجزیه را برای انتقال متوقف‌شده روی تونل زنده سرزنش کنید.
پینگ‌های کوچک تمام روز از تونل می‌گذرند، بنر SSH می‌رسد و همان لحظه که انتقال فایل شروع می‌شود نشست یخ می‌زند. این الگو به بودجه بایتی اشاره دارد که در لایه اشتباه شمرده شده است، جایی که تونل بیرونی برای سرباری خودش اندازه‌گیری شد و کسی تونل درونی را کم نکرد. بسته IPIP تودرتو برای WireGuard فقط یک بسته IP دیگر است و دقیقاً به همین دلیل بایت‌هایی را مصرف می‌کند که هرگز کنار نگذاشته بودید. اصلاح، حساب است و در سه فرمان و یک جدول جا می‌شود.
نشانه‌ای که آن را لو می‌دهد
مشکل تجزیه خود را با اندازه اعلام می‌کند، هرگز با نشانی‌ها. همتای شما یک ساعت به ping با اندازه 56 بایت پاسخ می‌دهد و سپس در 1400 بایت ساکت می‌شود، در حالی که تونل بالا می‌ماند و هیچ مسیری تغییر نکرده است. دست‌دادن جا می‌شود، نخستین پنجره کامل TCP جا نمی‌شود و انتقال چند ثانیه پس از سالم به نظر رسیدن متوقف می‌شود.
پیش از ویرایش هر چیزی سقف را اندازه بگیرید، چون سقف اندازه‌گیری‌نشده همان چیزی است که دو بار دنبالش می‌افتید. یک کاوشگر زیر اندازه مشکوک با بیت do-not-fragment روشن بفرستید، ping -M do -s 1000 10.9.0.2، و سپس آن را در اندازه‌ای که از قبل می‌دانید بیش از حد بزرگ است تکرار کنید. وقتی وارونگی از اندازه بار مفید پیروی می‌کند و مقصد بی‌تغییر می‌ماند، مسیریابی کار خود را می‌کند و یک سرآیند از بودجه کم است.
هر سرآیند را یک بار، در لایه درست بشمارید
از کوچک‌ترین MTU روی مسیر شروع کنید نه از رابط تونل، چون دیوار بالادست هر دو سر است. WireGuard 60 بایت را روی حمل بیرونی IPv4 خرج می‌کند: 20 برای IP، 8 برای UDP و 32 برای سرآیند خودش، و 80 بایت وقتی آن حمل IPv6 است. wg0 با 1420 بایت، 20 بایت فاصله ایمن زیر 1440 نگه می‌دارد که یک مسیر 1500 بایتی واقعاً می‌تواند تحویل دهد، و به همین دلیل عددی که از یک ویکی کپی شده هنوز اینجا جا می‌شود. تمام پشته را روی نمودار بنویسید، چون نفر بعدی که MTU را تغییر می‌دهد وگرنه یک عدد گرد تازه انتخاب می‌کند و اشکال شما را به ارث می‌برد.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
ردیف پنجم جایی است که بودجه‌ها خراب می‌شوند، چون 1400 بایتی که یک رابط تودرتو حمل می‌کند از قبل 40 بایت سرآیند خود بسته اصلی را در خود دارد. تنها 1360 از آن بایت‌ها به فرایندی می‌رسد که فایل را می‌خواند. 1400 را بار مفید برنامه بگیرید، چنان‌که هر نموداری بدون آن ستون شما را به آن دعوت می‌کند، و دستگاه درونی 40 بایت بیش از حد سخاوتمند در برابر دیواری که تکان نخورده است تمام می‌کند.
دو MTU را جداگانه تنظیم کنید
حامل و دستگاه تودرتو دو شیء جداگانه‌اند، پس هر کدام مقدار خودش را می‌خواهد. آن‌ها را به این ترتیب اعمال کنید، چون دستگاه تودرتو چیزی از حامل به ارث نمی‌برد:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400قاعده‌ای که ارزش به‌خاطرسپاری دارد: MTU درونی = MTU بیرونی - 20 وقتی بسته‌ای که تونل IPIP حمل می‌کند IPv4 است، و - 40 به‌محض آنکه هر یک از دو طرف بسته درونی IPv6 باشد، چون سرآیند تودرتو از 20 بایت به 40 رشد می‌کند. چیز دیگری به آن تفریق تعلق ندارد. سربار WireGuard همان موقع که 1420 را انتخاب کردید خرج شده بود، و گرفتن آن دو بار تونلی می‌سازد که بی‌نقص کار می‌کند و تا وقتی کسی اندازه‌اش نگیرد کند می‌ماند. استقرارهایی که هر دو دستگاه در آن 1400 گرد حمل می‌کنند اثر انگشت همین اشتباه است.
IPv6 در هر طرف بسته تودرتو همه اعداد بالا را باطل می‌کند، پس دوباره حساب کنید نه اینکه عددی از سایتی مشابه کپی کنید. سرآیندهای کاسته‌شده هر کدام 40 بایت‌اند به‌محض آنکه IPv6 در مسیر بیرونی یا در دیتاگرام اصلی ظاهر شود، و رقم بار مفید دقیقاً همان‌قدر پایین می‌آید.
قاعده فایروالی که احتمالاً به آن نیاز ندارید
بین دو همتای WireGuard تنها چیزی که روی سیم است UDP است، پس یک قاعده ورودی برای پروتکل 4، شماره‌ای که RFC 2003 به کپسوله‌سازی IPv4-در-IPv4 می‌دهد، نه مسیر تودرتو را می‌سازد و نه آن را زنده نگه می‌دارد. سرآیند IPIP درون بار مفید رمزنگاری‌شده زندگی می‌کند، جایی که هیچ فایروال لبه‌ای آن را نمی‌بیند. باز کردن پروتکل 4 به‌هرحال چیزی جز یک راه مجاز دیگر به میزبان نمی‌خرد.
سیاستی که به مبادی و مقاصد بسته اصلی اشاره می‌کند بعد از کپسول‌گشایی، روی رابط‌های تونل و در جدول مسیریابی جا دارد. آن را همان‌جا بگذارید و قاعده لبه می‌تواند بسته بماند.
WireGuard در واقع چه چیزی را اعتبارسنجی می‌کند
AllowedIPs درباره مبدأ بسته‌ای داوری می‌کند که WireGuard حمل می‌کند، و آنچه حمل می‌کند بسته کپسوله‌شده با IPIP است. مبدأ IPIP مجاز حتی وقتی سرآیند درونی میزبانی را نام می‌برد که ترجیح می‌دهید مسیریابی نکنید پذیرفته می‌شود. پس مبدأ اصلی چیزی نیست که همتا برای شما بررسی کرده باشد، و آن جفت نشانی درونی بعد از کپسول‌گشایی به اجرای خودش نیاز دارد.
پوشش ساختار مسیریابی می‌دهد، نه لایه دوم رمزنگاری. نامیدن IPIP به‌عنوان حفاظت اضافه درون WireGuard طراحی دیگری را توصیف می‌کند.
با نردبان تأیید کنید، نه با یک پینگ
اندازه‌هایی را که مرز محاسبه‌شده شما را دو طرفه در بر می‌گیرند بیازمایید، سپس تأیید کنید که هسته درباره هر دو دستگاه چه می‌اندیشد. با 1360 بایت بار مفید به‌علاوه 40 بایت سرآیند که 1400 می‌سازد، نخستین پژواک پایین جا می‌شود و دومی یک بایت آن‌سوی سقف می‌نشیند:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0عبور پاک زیر سقف و شکست در نخستین اندازه بالای آن یعنی حساب از سر تا ته برقرار است. سپس انتقالی را که ابتدا متوقف شده بود دوباره اجرا کنید، چون کاوشگر مصنوعی بودجه را ثابت می‌کند و درباره اندازه‌های نوشتن خود فرستنده چیزی نمی‌گوید. اگر مسیر تودرتو هنوز در اندازه‌ای که ثابت کردید جا می‌شود می‌شکند، پیش از بریدن ده بایت دیگر از MTU، کپسول‌گشایی و مسیرهای سر دور را بررسی کنید.