آیا ISP ترافیک UDP را مسدود می‌کند یا برنامهٔ داخل تونل؟

کسی گزارش می‌دهد که VPN «UDP را مسدود می‌کند»، و این عبارت دو ادعای کاملاً متفاوت را پنهان می‌کند. یکی دربارهٔ ترابری است که شبکهٔ دسترسی می‌بیند، و دیگری دربارهٔ بسته‌های یک برنامه پس از رمزگشایی در داخل تونل. یک تونل رمزگذاری‌شده را می‌توان بدون هیچ کلیدی از بیرون فیلتر کرد، و یک برنامهٔ UDP درونی می‌تواند به دلایلی شکست بخورد که هیچ ارتباطی با فیلترکردن ندارد. پیش از گردآوری شواهد تصمیم بگیرید کدام ادعا را می‌آزمایید.

دو سرایند، یک واژه

در استقرار IPsec با NAT-traversal، بستهٔ بیرونی UDP است که بین دو نقطهٔ پایانی VPN نشانی‌دهی می‌شود، معمولاً روی درگاه 4500. در داخل آن، بار رمزگذاری‌شده هر چیزی را حمل می‌کند که تونل ارسال می‌کند، و آن خودش می‌تواند TCP یا UDP باشد. بنابراین واژهٔ UDP دو بار با معنا و دیدپذیری متفاوت ظاهر می‌شود.

یک شبکهٔ میانی سرایند بیرونی را می‌بیند و هیچ چیز از سرایند درونی را نمی‌بیند. می‌تواند جریان بیرونی را مجاز کند، شکل دهد یا دور بریزد، و برای این کار لازم نیست چیزی را رمزگشایی کند. همین عدم تقارن تمام دلیل اشتباه گرفته شدن دو ادعاست: یک واژه هم آنچه شبکه فیلتر می‌کند و هم آنچه برنامه می‌فرستد را توصیف می‌کند. هر بار که یافته‌ای ثبت می‌کنید لایه را کنار واژه بنویسید، و سردرگمی تقریباً از میان می‌رود.

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

شبکه هنوز چه چیزی را می‌تواند ببیند

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

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

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

RFC 3948 کپسوله‌سازی بیرونی UDP را تعریف می‌کند، و مشخصات ESP چیدمان محافظت‌شده در داخل آن را تعریف می‌کند. هیچ‌یک از این دو سند تضمین نمی‌کند که شبکهٔ دسترسی جریان بیرونی را عبور دهد، و به همین دلیل آزمون دسترسی‌پذیری روی چندتایی بیرونی ارزش دارد پیش از هر نظریه‌ای دربارهٔ درونی. چندتایی بیرونی مسدودشده تونلی می‌سازد که هرگز شکل نمی‌گیرد، نه تونلی که شکل می‌گیرد و سپس یک برنامه را از دست می‌دهد.

چرا یک برنامهٔ UDP درون تونلِ کارکننده شکست می‌خورد

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

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

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

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

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

لایه را گزارش کنید، نه پروتکل را

یافته را در یکی از سه شکل بنویسید: تحویل بیرونی شکست خورد، ارسال درونی شکست خورد، یا برنامه شکست خورد. هر یک مالک متفاوتی دارد، و آمیختن آن‌ها بلیت را به تیم اشتباه می‌فرستد.

تغییر یک درگاه محلی نمی‌تواند در انتهای دور شنوندهٔ متناظر بسازد، بنابراین راه‌حل موقتی در سمت کلاینت که به نظر کمک می‌کند معمولاً شاهد آن است که مقصد اصلی اشتباه بوده است. به همین ترتیب، یک نمایهٔ جایگزین که ارائه می‌شود چیزی دربارهٔ دسترسی‌پذیری اثبات می‌کند و هیچ چیز دربارهٔ درست پیکربندی‌شدن برنامه.

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