Docker: در طول یک نشست VPN هیچ استخر آدرس از پیش تعریف‌شده‌ای باقی نمی‌ماند

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

پیش از تغییر هر چیزی تأیید کنید چه چیزی شکست خورده است

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

همزمان نسخه Engine را در تیکت ثبت کنید. هر اکتشافی در ادامه این راهنما به نسخه محدود است، و ادعای بی‌نسخه شایعه است.

تخصیص‌هایی را که همین حالا دارید بشمارید

شبکه‌ها را فهرست کنید و سپس مهم‌ها را بررسی کنید: docker network ls و پس از آن docker network inspect NETWORK_NAME. زیرشبکه‌های IPAM و کانتینرهای متصل به هرکدام را بخوانید. چند پروژه Compose بیش از آنچه شمار کانتینرهایشان نشان می‌دهد بلوک مصرف می‌کنند، چون هر پروژه گرایش دارد شبکه پیش‌فرض خودش را بسازد. کانتینر متوقف‌شده تخصیص شبکه‌اش را آزاد نمی‌کند.

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

عدد را بنویسید. همان خط پایه است که می‌گوید تغییر بعدی کمک کرد یا نه.

نگاه دیمن به مسیرها را مقایسه کنید

یک VPN می‌تواند بر انتخاب نامزدها اثر بگذارد، اما پیاده‌سازی دقیق تعیین می‌کند چگونه. در Moby 28.2.2 روی Linux، تابع InferReservedNetworks آدرس‌های سرور نام و برخی مسیرهای IPv4 on-link را جمع می‌کند و صرفاً هر مسیر از هر جدول را رزرو نمی‌کند. مسیرهای پیوند جمع‌آوری‌شده آدرس مقصد نامشخص را نیز کنار می‌گذارند، پس یک مسیر 0.0.0.0/1 به‌تنهایی همه آدرس‌ها را رزرو نمی‌کند. یک پیشوند گسترده دیگر روی پیوند، مانند 128.0.0.0/1، می‌تواند بازه‌های نامزد آشنا 172 و 192 را قطع کند.

ip -4 route show table all را پیش و پس از اتصال VPN، روی میزبان دیمن مقایسه کنید. تفاوت شاهد است، و نسخه دامنه ادعاست.

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

کوچک‌ترین اصلاحی را انتخاب کنید که کار می‌کند

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

تغییر default-address-pools خط‌مشی گسترده‌تری درباره تخصیص‌های آینده است. یک پایه بدون تعارض و اندازه تخصیص‌یافته مناسب انتخاب کنید، آن را با تنظیمات موجود دیمن ادغام کنید و اثر مستند راه‌اندازی مجدد را برنامه‌ریزی کنید. شبکه‌های موجود بی‌صدا شماره‌گذاری مجدد نمی‌شوند.

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

تخصیص و مسیریابی را جداگانه بپذیرید

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

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

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