تونل‌های تودرتوی VPN: چرا تونل داخلی روی بسته‌های بزرگ متوقف می‌شود
هر تونل بخشی از بودجه بسته‌های مسیر را پیش از شروع بعدی خرج می‌کند. سرآیندها را جمع کنید و نشست داخلی روی بسته‌های بزرگ شکست می‌خورد.
DNS حل می‌شود، نشست SSH برپا می‌ماند، و سپس یک بارگذاری بزرگ قفل می‌شود در حالی که ping به همان میزبان هنوز پاسخ می‌دهد. این شکاف به اندازه بسته اشاره دارد نه به تونل خراب. تونل‌های تودرتو به اندازه‌هایی می‌رسند که هیچ‌کدام از تونل‌ها به‌تنهایی به آن نمی‌رسید. نشست داخلی سالم است؛ فقط بسته‌هایی به آن داده می‌شود که دیگر جا نمی‌شوند.
MTU مسیر واقعاً کجا می‌رود
هر کپسوله‌سازی بایت‌هایی خرج می‌کند پیش از آنکه لایه بعدی نوبتش برسد. یک مسیر Ethernet 1500 بایت به بسته بیرونی عرضه می‌کند، و تونل بیرونی سهم خود را پیش از آنکه چیزی درونش آدرس‌دهی شود برمی‌دارد. یک مقدار سرباری حدس‌زده دقیقاً به همان اندازه‌ای که مهم است اشتباه خواهد بود.
لایه‌ها را به ترتیب فهرست کنید: مسیر دسترسی، انتقال بیرونی، تونل بیرونی، انتقال داخلی، تونل داخلی، برنامه. هر سرآیند را یک بار بشمارید، و UDP را از سرآیند و برچسب خود تونل جدا نگه دارید.
دو لایه WireGuard، یک بار شمرده
یک مسیر دسترسی IPv4 با یک تونل WireGuard درون تونلی دیگر بردارید. لایه بیرونی 20 بایت IPv4، 8 بایت UDP و 32 بایت برای سرآیند داده WireGuard به‌همراه برچسب احراز هویت آن هزینه دارد. درون آن، تونل داخلی به سرآیند 20 بایتی IPv4 و سرآیند 8 بایتی UDP خودش پیش از 32 بایت دوم سربار WireGuard نیاز دارد. آنچه می‌ماند یک سرآیند IPv4، یک سرآیند TCP و داده‌ها را جای می‌دهد. مسیر بیرونی IPv6 به‌جای 20، 40 هزینه دارد و 1320 باقی می‌گذارد.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
حساب به 1340 بایت می‌رسد. یک لایه با همان قواعد 1400 بایت برای بار مفید TCP باقی می‌گذارد، یعنی 1500 منهای 20، 8، 32، 20 و 20، و اختلاف 60 بایتی دقیقاً همان کپسوله‌سازی داخلی است که تونل دوم اضافه می‌کند.
1400 را روی یک مسیر تودرتو اعمال کنید و تونل داخلی 60 بایت کم می‌آورد، نامرئی تا زمانی که بسته به‌قدر کافی بزرگ شود که به آن‌ها نیاز داشته باشد. پدینگ و گزینه تکه‌تکه‌سازی خود پروتکل دوباره ارقام را جابه‌جا می‌کنند، پس به جدول اعتماد کنید.
MTU، MSS و تکه‌تکه‌سازی در جاهای متفاوتی عمل می‌کنند
MTU رابط محدود می‌کند که رابط چه چیزی بیرون بدهد، در حالی که فشرده‌سازی MSS در TCP تغییر می‌دهد که همتای TCP حاضر است چه بفرستد. فشرده‌سازی نشست‌های TCP را درست می‌کند و برای یک دیتاگرام بزرگ UDP هیچ کاری نمی‌کند، این‌گونه یک اصلاح برای یک برنامه موفق به نظر می‌رسد و بی‌صدا برنامه بعدی را از دست می‌دهد. گزینه تکه‌تکه‌سازی خود پروتکل اهرم سومی است با شکست‌های خودش. MTU رابط نخستین حرکت رایج و خشن‌ترین آن است.
تونل‌های پل‌شده و مسیریابی‌شده قاب‌های متفاوتی حمل می‌کنند، بنابراین ارقام یک استقرار دیگر به‌ندرت منتقل می‌شوند. کشف MTU مسیر، که در RFC 8201، تنها تا زمانی کمک می‌کند که پیام‌های ICMP که به آن‌ها وابسته است اجازه عبور داشته باشند.
یافتن لایه‌ای که کم می‌آورد
اگر الزامات اجازه مقایسه بدهند، هر تونل را جداگانه پیش از تودرتو کردن بررسی کنید. یک کاوشگر با اندازه ثابت آن را روشن می‌کند: ping -M do -s 1472 -c 3 10.8.0.1 یک بسته کامل IPv4 با 1500 بایت درون آن لایه می‌فرستد. لایه دوم را اضافه کنید و همان کاوشگر را تکرار کنید تا هر شکستی به یک تغییر شناخته‌شده تعلق داشته باشد.
وقتی انتقالی متوقف می‌شود، هر بار یک پارامتر مستند را تغییر دهید و اندازه‌ای را که شکست می‌خورد ثبت کنید. مسیر بازگشت را هم بررسی کنید، زیرا بازگشت تودرتوی مسیرها می‌تواند مشکل اندازه بسته را به‌قدری دقیق تقلید کند که یک بعدازظهر هزینه داشته باشد. یک پاسخ فیلترشده ICMP می‌تواند حد واقعی را پنهان کند، پس کاوشگر از استدلال مهم‌تر است.
بودجه را جایی بنویسید که نفر بعدی پیدایش کند
جدولی با یک ردیف برای هر لایه از یک قاعده سرانگشتی بیشتر عمر می‌کند. آن را کنار نمودار تونل نگه دارید تا هیچ‌کس حساب را زیر فشار دوباره نکند.
تونل‌های بیشتر یعنی وابستگی‌های بیشتر، پس یک برنامه بازگشت جای خود را کنار بودجه به دست می‌آورد. اگر ارقام هنوز جمع نمی‌شوند، به‌جای حدس دوباره، مسیر را اندازه بگیرید. هدف رقمی است که بتوانید از آن دفاع کنید، نه اینکه به خاطر بسپارید.