HTTPS داخل کانتینر روی VPN شرکتی گیر می‌کند؟ پایه DTLS را آزمایش کنید

داخل کانتینری پشت یک VPN شرکتی، DNS حل می‌شود، صفحه ورود بارگذاری می‌شود، یک نقطه پایانی سلامت پاسخ می‌دهد و سپس یک درخواست HTTPS تا پایان مهلت گیر می‌کند. بازسازی ایمیج و تغییر متغیرهای پروکسی هیچ چیز را عوض نمی‌کند، چون بخش خراب در ایمیج نیست. کلاینت از طریق یک انتقال احراز هویت می‌کند و داده‌های حجیم را از انتقال دیگری عبور می‌دهد و فقط دومی خراب است.

دو انتقال، یک نشانه گیج‌کننده

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

کانتینر آن مذاکره را تغییر نمی‌دهد؛ مسیری را تغییر می‌دهد که بسته‌های بیرونی طی می‌کنند. میزبان جریان کانتینر را ترجمه می‌کند، پس دیتاگرام‌های UDP از پورت مبدأ متفاوتی نسبت به سوکت محلی کلاینت خارج می‌شوند و از طریق یک ورودی ترجمه بازمی‌گردند که با تایمری بسیار کوتاه‌تر از یک جریان TCP برقرار منقضی می‌شود. اگر تونل روی میزبان کار می‌کند و در کانتینر شکست می‌خورد، پیش از متهم کردن برنامه آن دو جریان را مقایسه کنید. این مقایسه بیش از هر بازسازی ایمیج چیزی را روشن می‌کند.

با آزمایش تصمیم بگیرید، نه با شهود

ارزان‌ترین آزمایش کانال داده UDP را غیرفعال و درخواست را تکرار می‌کند. از کلاینت خط فرمان به جای پوسته دسکتاپ استفاده کنید تا پرچم واقعاً اعمال شود: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. اگر درخواستی که گیر کرده بود اکنون کامل می‌شود، پایه DTLS مشکل بود و بقیه نویز.

نتیجه را در هر دو جهت از همان کانتینر تأیید کنید: یک درخواست حجیم با پرچم و یکی بدون آن. تغییر رفتاری که پرچم را دنبال می‌کند شواهد است؛ صفحه‌ای که سرانجام بارگذاری می‌شود شواهد نیست.

اگر پرچم آن را درست کرد، تصمیم بگیرید چرا

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

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

پیش از نگه داشتن راه‌حل موقت اندازه بسته را بررسی کنید

اگر اندازه علت باشد، رابط تونل بسته‌هایی را می‌پذیرد که مسیر نمی‌تواند حمل کند، و مشکل به محض بزرگ شدن بار بر هر انتقالی بازمی‌گردد. رابط‌ها را مقایسه کنید: ip link show tun0 روی میزبان، سپس docker network inspect bridge برای خواندن MTU ثبت‌شده در گزینه‌های شبکه. پل کانتینری که زیر تونلی که کمتر حمل می‌کند هنوز روی 1500 بایت است، یافته معمول است.

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

تصمیم بگیرید چه چیزی را حاضرید معامله کنید

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

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