کلید قطع برای کنتینر جانبی VPN: ترافیک را هنگام خروجش مسدود کن

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

چرا اشتراک فضای نام یک kill switch نیست

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

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

واقعاً چه اتفاقی می‌افتد وقتی کنتینر خارج می‌شود

سه رویداد را از هم جدا کنید. فرایند VPN داخل کنتینر می‌تواند بمیرد در حالی که کنتینر به کار ادامه می‌دهد. کنتینر می‌تواند متوقف یا حذف شود، که فضای نام را نابود می‌کند. کنتینر می‌تواند دوباره ساخته شود، که فضای نام تازه و قواعد تازه می‌سازد.

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

یک سیاست خروج صریح بسازید

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

استثنای نقطه پایانی باید پیش از بالا آمدن تونل برقرار باشد، وگرنه کلاینت VPN نمی‌تواند به سرور خود برسد. به همین دلیل مجموعه قواعد صراحتاً انتقال بیرونی را مجاز می‌کند نه اینکه رابط فیزیکی را به‌طور کلی مجاز کند. قواعد IPv6 را هم اضافه کنید اگر فضای نام اتصال IPv6 دارد، زیرا سیاستی که فقط IPv4 را پوشش می‌دهد خانواده دیگر را باز می‌گذارد.

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

چرخه عمر را آزمایش کنید، نه فقط قطع اتصال را

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

به یک بررسی سلامت یا جست‌وجوی IP خروجی به‌عنوان سازوکار مسدودسازی تکیه نکنید. بررسی وضعیت را مشاهده و گزارش می‌کند؛ سیاست ترافیک را کنترل می‌کند. هر دو به همان استقرار تعلق دارند، و جایگزین یکدیگر نیستند.

قواعد را ثبت کنید تا آزمون از یک به‌روزرسانی جان سالم ببرد

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

مسیر بیرونی لازم نقطه پایانی VPN را از خروج نامحدود برنامه جدا نگه دارید و DNS و IPv6 را در پوشش مورد نظر نگه دارید. اگر سیاست کل رابط فیزیکی را برای راحتی مجاز کند، kill switch از میان رفته است. مستندات شبکه Docker چیدمان فضای نام مشترکی را که سیاست بر آن بنا شده توصیف می‌کند، و همان مرجعی است که هنگام تردید در رفتار محیط اجرا باید بررسی شود.