خطای همپوشانی pool در Docker مشکل مسیر VPN نیست

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

دو خطای شبیه به هم

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

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

هر دو مشکل طرح نشانی هستند. فقط یکی از آن‌ها مشکل Docker است.

نخست poolهای تخصیص‌یافته را بخوانید

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

docker network ls
docker network inspect EXISTING_NETWORK

آن زیرشبکه را با poolی که شبکه جدید درخواست می‌کند مقایسه کنید، و به یاد داشته باشید که Compose برای هر پروژه شبکه پیش‌فرض خودش را می‌سازد. تعارض با پروژه‌ای که فراموش کرده‌اید دقیقاً مانند تعارض با daemon به نظر می‌رسد.

ipv4_address ایستا روی یک سرویس نشانی یک کانتینر است، نه تعریف pool. تغییر آن همپوشانی را برطرف نمی‌کند، چون همپوشانی میان زیرشبکه‌های شبکه است نه میان کانتینرها. مرجع network-create در Docker برای تخصیص معمول پل زیرشبکه‌های بدون همپوشانی را لازم می‌داند و مستند می‌کند که چگونه یکی را آشکارا انتخاب کنید.

پیشوندی برگزینید که از VPN جان سالم به در ببرد

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

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

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

شبکه را آگاهانه بازنشسته یا تغییر دهید

برای شبکه جدید Compose، پیشوند بلااستفاده را در پیکربندی IPAM شبکه تنظیم کنید. برای پروژه موجود، شماره‌گذاری مجدد را برنامه‌ریزی کنید: نشانی‌های ثابت، سرویس‌های وابسته و گام بازسازی شبکه همه باید در نظر گرفته شوند، چون ویرایش YAML یک شبکه در حال اجرا را شماره‌گذاری مجدد نمی‌کند.

اگر شبکه‌ای منسوخ تخصیص متعارض را در اختیار دارد، پیش از حذف آن بررسی کنید چه کسی متصل است. docker network rm تا زمانی که endpointهای فعال وجود دارند خودداری می‌کند، و docker stop نام یا ID کانتینرها را می‌گیرد نه نام شبکه. توقف یک کانتینر نیز تعریف شبکه‌ای را که pool را نگه می‌دارد حذف نمی‌کند.

prune گسترده ابزار تشخیصی نیست. به پروژه‌های بی‌ربط می‌رسد و شواهدی را که در آستانه جمع‌آوری بودید نابود می‌کند.

poolهای پیش‌فرض فقط به تخصیص بعدی کمک می‌کنند

تنظیم pool نشانی پیش‌فرض daemon تخصیص‌های خودکار آینده را با نگه داشتن آن‌ها بیرون از بازه‌هایی که رزرو می‌کنید بهبود می‌بخشد. این شبکه‌های موجود را به‌صورت گذشته‌نگر دوباره نشانی‌دهی نمی‌کند، و زیرشبکه صریحی را که با زیرشبکه صریح دیگری همپوشانی دارد حل نمی‌کند.

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

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

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