چرا مسدود کردن کامل ICMP یک مسیر VPN سالم را می شکند
پیام های بازخورد اندازه پاسخ های ping نیستند. وقتی هرگز نمی رسند، بسته های کوچک موفق می شوند، بسته های بزرگ ناپدید می شوند و تونل شبیه لرزش به نظر می رسد.
تونلی که احراز هویت می شود، یک ping را حمل می کند و سپس در نخستین انتقال بزرگ گیر می کند، نشانه کلاسیک یک پیام ICMP گمشده است نه VPN خراب. فرستنده هرگز نمی فهمد که بسته بیش از حد بزرگ بوده، همان اندازه را تکرار می کند و برنامه منتظر می ماند. رفع این مشکل تصمیمی در سیاست دیوار آتش است، نه نصب دوباره کلاینت. ترتیب مهم است: اندازه گیری کنید مرز اندازه کجاست، سپس قاعده ای را که گزارش را بلعیده تنگ کنید.
ICMP در این مسیر واقعاً چه چیزی حمل می کند
کشف MTU مسیر IPv4 به این وابسته است که مسیریاب گزارش دهد بسته ای با بیت don't-fragment تنظیم شده قابل ارسال نبوده است. آن گزارش پیام ICMP Fragmentation Needed است و بدون آن فرستنده دلیلی برای کاهش اندازه قطعه خود ندارد. IPv6 سخت گیرتر است: مسیریاب ها در مسیر ترانزیت تکه تکه نمی کنند، پس پیام ICMPv6 Packet Too Big تنها نشانه ای است که فرستنده را به کوچک شدن وادار می کند.
هر دو پیام بازخورد سطح کنترل هستند و هیچ کدام پژواک تشخیصی نیستند. سیاستی که ping را مسدود می کند و سیاستی که همه ICMP را مسدود می کند در فهرست قواعد شبیه هم به نظر می رسند اما روی شبکه بسیار متفاوت رفتار می کنند. دومی می تواند یک تونل درست اندازه بندی شده را برای هر چیزی بزرگ تر از کوچک ترین حلقه زنجیره به مسیری یک طرفه تبدیل کند.
برخی حامل ها کشف خود را با بسته های کاوشی پیاده می کنند، همان طور که RFC 4821 توصیف می کند، و کمتر به این بازخورد وابسته اند. این استدلالی برای بررسی این است که کدام حامل را اجرا می کنید، نه برای فرض اینکه هر تونلی مصون است.
| پیام | هدف در مسیر | اگر مسدود شود |
|---|---|---|
| ICMPv4 نوع 3 کد 4 | بسته برای حلقه بعدی بیش از حد بزرگ بود | فرستنده مدام تکرار می کند و گیر می کند |
| ICMPv6 نوع 2 | Packet Too Big، معادل IPv6 | همان توقف، بدون جایگزین تکه تکه سازی |
| ICMP نوع 11 | زمان منقضی شد، traceroute از آن استفاده می کند | تشخیص گام ها را از دست می دهد، ترافیک همچنان جریان دارد |
| درخواست و پاسخ پژواک ICMP | آزمون دسترس پذیری | ping شکست می خورد، ممکن است مسیر سالم باشد |
خرابی به اندازه بستگی دارد
بپرسید آیا خرابی با اندازه بسته همبستگی دارد. صفحه ورود، پرس وجوی DNS و فراخوانی کوتاه API موفق می شوند، در حالی که بارگذاری فایل، پاسخ بزرگ یا دانلود تصویر گیر می کند. این الگو به محدودیتی در اندازه جایی بین دو سر اشاره می کند، نه به احراز هویت یا مسیریابی. یک ping کوچک موفق تقریباً هیچ چیزی درباره جای آن مرز نمی گوید.
درون تونل دو لایه باید در نظر گرفته شود: بسته بار مفید و بسته بیرونی کپسوله شده. فرستنده درونی می تواند درست رفتار کند در حالی که مسیر بیرونی کوچک تر از فرض تونل است، و به همین دلیل هم تنظیم MTU خود تونل و هم پیوند فیزیکی زیر آن اهمیت دارند.
پیش از ویرایش قواعد اندازه گیری کنید
با بیت don't-fragment و اندازه بار مفیدی که خودتان انتخاب می کنید کاوش کنید، از کلاینت معیوب به سوی یک نشانی محافظت شده:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7بار مفید 1472 بایت به علاوه 28 بایت سرآیند یک بسته 1500 بایتی می سازد. اگر کاوش بزرگ با خطای تکه تکه سازی شکست بخورد و کاوش کوچک عبور کند، مرز را یافته اید؛ برای سرباز تونل تنظیم کنید و تکرار کنید تا اندازه کارآمد پایدار شود.
سپس تأیید کنید که شکاف خود گزارش است. اگر کاوش بی صدا شکست بخورد، بدون خطا و بدون پاسخ، احتمالاً پیام حذف می شود نه تحویل، و مظنون همان قاعده است.
قاعده را تنگ کنید، سپس وظیفه را دوباره بیازمایید
اصلاح باید پیام های کنترل مشخص را مجاز کند، نه کل پروتکل را. روی میزبان iptables شکل کار یک پذیرش نوع محور است؛ نحو را با آنچه دیوار آتش را روی سکوی شما مدیریت می کند تطبیق دهید:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTاگر سیاست محلی این است، پاسخ های پژواک را مسدود نگه دارید، چون مسیر به آن ها نیاز ندارد. سپس انتقالی را که در ابتدا شکست خورده بود از یک اتصال تازه دوباره بیازمایید و تأیید کنید که شمارنده های قاعده رسیدن پیام ها را نشان می دهند.
اگر انتقال بزرگ پس از مجاز شدن پیام ها همچنان گیر می کند، محدودیت باقی مانده جای دیگری است: MTU تونلی که بیش از حد بالا تنظیم شده، پروکسی ای که بسته ها را بازنویسی می کند، یا جعبه میانی ای که به جای گزارش کردن دور می ریزد. قاعده ICMP لازم بود، نه کافی.