به‌اشتراک‌گذاشتن شبکه یک کانتینر VPN: چه اتفاقی برای DNS می‌افتد

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

گام 1: از برنامه آزمایش کنید، نه از میزبان

جستجو را داخل کانتینری که مشکل دارد اجرا کنید، نه روی میزبان و نه در مرورگر. docker exec app-container getent hosts db.internal به تنها سؤالی پاسخ می‌دهد که اهمیت دارد: resolver این فرایند چه چیزی برمی‌گرداند.

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

گام 2: مدل پشتیبانی‌شده runtime را بخوانید

مستندات شبکه Docker محدودیت‌هایی را درباره پرچم‌های DNS برای کانتینرهایی که حالت شبکه کانتینر دیگری را به اشتراک می‌گذارند ثبت می‌کند. در Compose، network_mode: service:vpn برنامه را به فضای نام کانتینر VPN گره می‌زند، و برای هر سرویس dns تنظیمات به همان شکلی که برای یک سرویس معمولی عمل می‌کنند عمل نمی‌کنند. راه‌حلی که دریافت می‌کنید همان است که فضای نام مشترک دارد.

شبکه‌های پل تعریف‌شده توسط کاربر نیز DNS تعبیه‌شده Docker را متفاوت از پل پیش‌فرض به کار می‌گیرند. به همین دلیل یک dns بند که از یک نمونه پل کارآمد کپی شده باشد می‌تواند در یک پشته مشترک اصلاً هیچ کاری نکند. پیش از کپی کردن بند، ترتیب را بررسی کنید.

یک نشانی loopback همیشه به زمینه شبکه مربوطه اشاره دارد. درون یک فضای نام مشترک، 127.0.0.1 resolver میزبان نیست.

گام 3: پرس‌وجو را تا گیرنده‌اش دنبال کنید

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

صفحه بررسی IP در مرورگر نمی‌تواند بگوید پرس‌وجوهای نام کجا رفته‌اند. فقط می‌گوید یک اتصال HTTP کجا رفته است.

گام 4: دو دسته خرابی را متفاوت رفع کنید

اگر نام‌های سرویس شکست بخورند در حالی که نام‌های عمومی کار می‌کنند، مشکل در کشف سرویس درون شبکه کانتینرها است، نه فهرست resolverهای عمومی. تغییر هر نشانی DNS عمومی رکوردهایی را ایجاد نمی‌کند که هرگز از سازوکار کشف شبکه خواسته نشده است.

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

گام 5: پس از بازسازی دوباره آزمایش کنید

پیکربندی را از طریق سازوکار پشتیبانی‌شده runtime تغییر دهید، سپس کانتینرها را بازسازی کنید به‌جای ویرایش فایل‌ها در یک کانتینر در حال اجرا. یک نام خصوصی تازه، یک نام عمومی تازه و درخواست برنامه‌ای را که پس از جستجو می‌آید آزمایش کنید. ویرایشی در /etc/resolv.conf درون یک کانتینر با بازسازی ناپدید می‌شود و شما را متقاعد می‌کند که تعمیر کار کرده است، در حالی که نکرده است.

مالک resolver و فضای نام مورد انتظار را کنار تعریف شبکه مشترک ثبت کنید. نفر بعدی به هر دو نیاز خواهد داشت.