پینگ VPN کار می‌کند اما وب‌سایت قطع می‌شود: اندازه را بررسی کنید

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

از کوچک‌ترین پرسش به بزرگ‌ترین بروید و بنویسید هر گام واقعاً چه چیزی را ثابت کرد.

پاسخ اکو به پرسشی بسیار کوچک‌تر پاسخ می‌دهد

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

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

بفهمید آیا اتصال آغاز شده است

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

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

اندازه را با عددی اعلام‌شده اندازه بگیرید

وقتی گیر کردن زیر بار ظاهر می‌شود، یک اندازه بسته را با بیت ممنوعیت قطعه‌بندی روشن بیازمایید و حساب آن را ذکر کنید تا نتیجه معنایی داشته باشد. در لینوکس با iputils، بار مفید 1392 بایتی به‌همراه سرآیند 8 بایتی ICMP و سرآیند 20 بایتی IPv4 بسته‌ای درونی دقیقاً 1420 بایتی می‌سازد. آن حساب را در تیکت بنویسید، چون پینگ خالی که به دروازه می‌رسد درباره یک برنامه چیزی ثابت نمی‌کند.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

مسیر بیرونی را حساب کنید

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

کشف MTU مسیر در IPv4 به بازخورد درباره بسته‌هایی وابسته است که بدون قطعه‌بندی قابل ارسال نیستند، و IPv6 از پیام‌های Packet Too Big استفاده می‌کند. مشخصات IPv4 آن سازوکار را توصیف می‌کند. فیلتر کردن بازخورد توانایی یادگیری فرستنده را می‌شکند و او را به فرستادن دوباره بسته‌هایی وا می‌گذارد که هرگز جا نمی‌شوند. به همین دلیل است که یک درخواست کوچک کارآمد و یک درخواست بزرگ ناکام این‌قدر راحت با هم زندگی می‌کنند.

یک عدد را تغییر دهید و برنامه را دوباره بیازمایید

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

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

اگر برنامه با هر اندازه‌ای که آزمودید کار می‌کند، تنظیم اعداد را رها کنید و به سیاستی نگاه کنید که سرویس کارآمد را از سرویس ناکام جدا می‌کند.