Amir Jabbari
در بسیاری از این خطاها Docker سالم است و حتی کانتینر بدون مشکل اجرا می‌شود؛ اما بسته‌های خروجی کانتینر در مرحله Forward یا NAT متوقف می‌شوند. در Docker Engine جدید نیز امکان استفاده مستقیم از nftables وجود دارد، بنابراین قبل از تغییر قوانین باید مشخص کنیم Docker واقعاً از کدام Firewall Backend استفاده می‌کند.
ابتدا اینترنت Host را از اینترنت Container جداگانه آزمایش کنید. سپس IP Forwarding، وضعیت FORWARD، قوانین NAT و backend فایروال Docker را بررسی کنید. اگر بعد از مهاجرت از iptables به nftables مشکل ایجاد شده، باقی‌ماندن policy برابر DROP در FORWARD یکی از مهم‌ترین مواردی است که باید بررسی شود.
nftables چه ارتباطی با اینترنت Docker دارد؟
کانتینری که به شبکه Bridge داکر متصل است معمولاً مستقیماً از کارت شبکه اصلی سرور استفاده نمی‌کند. Docker یک شبکه مجازی ایجاد می‌کند و ترافیک کانتینر برای رسیدن به اینترنت باید از Host عبور کند.
در این مسیر چند بخش اهمیت دارند:
🔹 رابط Bridge مانند docker0 یا Bridge اختصاصی شبکه Compose
🔹 فعال بودن IP Forwarding در Kernel
🔹 قوانین Forward فایروال
🔹 NAT و Masquerading برای تبدیل آدرس خصوصی کانتینر
🔹 قوانین ساخته‌شده توسط خود Docker
اگر یکی از این بخش‌ها مسدود شود، ممکن است Host همچنان اینترنت داشته باشد ولی کانتینر نتواند حتی یک IP عمومی را Ping کند.
نشانه‌های رایج مشکل nftables در Docker
قبل از دست‌کاری فایروال، مطمئن شوید مشکل واقعاً در لایه شبکه Docker قرار دارد. چند علامت متداول عبارت‌اند از:
🔹 اینترنت Ubuntu یا Debian سالم است ولی کانتینر اینترنت ندارد.
🔹 دستورهای apt update، curl یا دانلود پکیج داخل کانتینر Timeout می‌شوند.
🔹 کانتینر IP گرفته اما به Gateway یا اینترنت دسترسی ندارد.
🔹 مشکل بلافاصله پس از تغییر nftables، UFW یا Docker ایجاد شده است.
🔹 بعد از مهاجرت Firewall Backend از iptables به nftables ارتباط قطع شده است.
🔹 سرویس Docker اجرا می‌شود اما Port Publishing یا دسترسی خارجی کانتینر درست کار نمی‌کند.
مرحله ۱: ابتدا اینترنت خود سرور را بررسی کنید
این دستورات را روی خود VPS و خارج از کانتینر اجرا کنید:
ping -c 4 1.1.1.1
curl -I https://example.comاگر این دستورات نیز شکست می‌خورند، هنوز نمی‌توان مشکل را به Docker نسبت داد. ابتدا Route، DNS، کارت شبکه و فایروال خود Host را بررسی کنید.
اگر Host اینترنت دارد، به مرحله بعد بروید.
مرحله ۲: اینترنت داخل کانتینر را جداگانه تست کنید
یک تست ساده با کانتینر موقت انجام دهید:
docker run --rm alpine ping -c 4 1.1.1.1اگر این تست موفق باشد، مسیر IP و NAT احتمالاً کار می‌کند و بهتر است DNS را جداگانه بررسی کنید:
docker run --rm alpine ping -c 4 example.comاگر IP عمومی در دسترس است ولی نام دامنه Resolve نمی‌شود، مشکل احتمالاً DNS است و تغییر nftables لزوماً راه‌حل مناسبی نیست.
اما اگر حتی 1.1.1.1 نیز از کانتینر قابل دسترس نیست، Forwarding، NAT و Firewall را بررسی کنید.
مرحله ۳: وضعیت IP Forwarding را بررسی کنید
Docker برای بسیاری از قابلیت‌های شبکه Bridge به IP Forwarding نیاز دارد.
sysctl net.ipv4.ip_forwardخروجی مورد انتظار برای IPv4:
net.ipv4.ip_forward = 1اگر مقدار صفر است، می‌توانید برای آزمایش موقت آن را فعال کنید:
sudo sysctl -w net.ipv4.ip_forward=1سپس دوباره اینترنت کانتینر را تست کنید.
فعال‌کردن IP Forwarding به‌تنهایی مشخص نمی‌کند چه ترافیکی اجازه عبور داشته باشد. مخصوصاً روی سروری با چند رابط شبکه باید قوانین فایروال مناسب برای جلوگیری از Forward ناخواسته وجود داشته باشد.
مرحله ۴: مشخص کنید Docker از چه Firewall Backend استفاده می‌کند
در نسخه‌های جدید Docker امکان انتخاب backend فایروال وجود دارد. ابتدا نسخه Docker را ببینید:
docker versionسپس فایل تنظیمات daemon را بررسی کنید:
sudo cat /etc/docker/daemon.jsonاگر این فایل وجود نداشت، لزوماً مشکلی وجود ندارد. Docker می‌تواند با تنظیمات پیش‌فرض اجرا شود.
در Docker Engine 29 امکان استفاده از گزینه firewall-backend برای انتخاب nftables فراهم شده است. پشتیبانی مستقیم nftables در این شاخه هنوز باید با توجه به نسخه دقیق Docker و محدودیت‌های آن بررسی شود؛ بنابراین صرف اینکه سیستم‌عامل شما nftables دارد به این معنی نیست که حتماً باید Docker را به backend جدید منتقل کنید.
مرحله ۵: قوانین nftables را بدون تغییر مشاهده کنید
فعلاً هیچ Rule را حذف نکنید. ابتدا Ruleset موجود را ببینید:
sudo nft list rulesetاگر Docker با backend مستقیم nftables کار کند، در نسخه‌های فعلی برای شبکه‌های Bridge جدول‌هایی مرتبط با Docker ایجاد می‌کند. قوانین متعلق به Docker را مستقیماً ویرایش نکنید؛ Docker انتظار دارد مدیریت این بخش‌ها در اختیار خودش باشد و تغییر دستی ممکن است با Restart بعدی از بین برود یا شبکه را دچار وضعیت غیرقابل پیش‌بینی کند.
مرحله ۶: policy زنجیره FORWARD را بررسی کنید
این مرحله به‌خصوص بعد از مهاجرت از iptables به nftables مهم است.
sudo iptables -L FORWARD -n -v
sudo ip6tables -L FORWARD -n -vبه ابتدای خروجی توجه کنید. ممکن است چیزی شبیه این ببینید:
Chain FORWARD (policy DROP)این وضعیت الزاماً به‌تنهایی خطا نیست. اما هنگام مهاجرت Docker از backend قدیمی به nftables، یک policy قدیمی DROP می‌تواند باعث شود بسته‌ای که از قوانین nftables عبور کرده است بعداً در مسیر iptables Drop شود.
برای تشخیص موقت، در محیطی که مطمئن هستید تغییر Forward Policy باعث بازشدن مسیر ناخواسته بین رابط‌های شبکه نمی‌شود، می‌توان policy را موقتاً آزمایش کرد:
sudo iptables -P FORWARD ACCEPTسپس بلافاصله تست کنید:
docker run --rm alpine ping -c 4 1.1.1.1اگر اینترنت فوراً برقرار شد، محل مشکل تقریباً مشخص شده است: مسیر Forward توسط policy یا Rule دیگری مسدود شده است.
روی Host چندکاره یا سیستمی که نقش Router دارد، ACCEPT کردن عمومی Forward می‌تواند مسیرهایی را باز کند که قبلاً مسدود بوده‌اند. بعد از تشخیص علت باید Rule دقیق متناسب با معماری شبکه ساخته شود.
مرحله ۷: NAT و Masquerading را بررسی کنید
کانتینرهای Bridge معمولاً آدرس خصوصی دارند. برای دسترسی آن‌ها به اینترنت باید NAT/Masquerading به‌درستی انجام شود.
در سیستم‌هایی که Docker با iptables کار می‌کند، وضعیت NAT را می‌توانید با دستور زیر مشاهده کنید:
sudo iptables -t nat -L -n -vهمچنین شبکه‌های Docker را بررسی کنید:
docker network ls
docker network inspect bridgeدر خروجی Inspect می‌توانید Subnet، Gateway و تنظیمات شبکه Bridge را مشاهده کنید.
چرا نباید iptables را در daemon.json غیرفعال کنیم؟
یکی از راه‌حل‌هایی که در بعضی آموزش‌ها دیده می‌شود، افزودن تنظیمی شبیه غیرفعال‌کردن مدیریت iptables توسط Docker است. این کار برای رفع عمومی مشکل nftables توصیه نمی‌شود.
Docker برای شبکه‌های Bridge به Ruleهای Firewall و NAT نیاز دارد. اگر تولید این Ruleها را متوقف کنید و جایگزین کامل آن‌ها را خودتان نسازید، ممکن است Masquerading از بین برود و کانتینرها دیگر نتوانند به اینترنت دسترسی پیدا کنند.
به همین دلیل تغییر این تنظیم باید فقط در معماری‌هایی انجام شود که مدیر شبکه قصد دارد تمام Ruleهای مورد نیاز Docker را خودش مدیریت کند.
تداخل UFW با Docker و nftables
اگر روی Ubuntu از UFW استفاده می‌کنید، وضعیت آن را نیز بررسی کنید:
sudo ufw status verboseDocker و UFW مسیر پردازش ساده‌ای ندارند. Port Publishing داکر می‌تواند از مسیر NAT عبور کند پیش از آنکه قواعد معمول INPUT و OUTPUT در UFW آن را به شکلی که انتظار دارید پردازش کنند.
بنابراین دو نتیجه مهم داریم: خاموش‌کردن UFW نباید اولین راه‌حل باشد و صرفاً وجود یک Rule در UFW نیز تضمین نمی‌کند ترافیک Published Port دقیقاً همان‌طور که تصور می‌کنید فیلتر شود.
بعد از تغییر فایروال Docker را Restart کنیم؟
پس از اصلاح تنظیمات مرتبط با Docker daemon، ابتدا صحت فایل تنظیمات را بررسی کنید و سپس سرویس را Restart کنید:
sudo systemctl restart docker
sudo systemctl status docker --no-pagerاگر سرویس بالا نیامد، لاگ را بررسی کنید:
sudo journalctl -u docker -n 100 --no-pagerخطاهای مربوط به Forwarding، Firewall Backend، Network Controller و ساخت Bridge در این خروجی اهمیت دارند.
یک تست کامل بعد از رفع مشکل
فقط روشن‌شدن Docker کافی نیست. ابتدا وضعیت سرویس را بررسی کنید:
docker info
docker network lsسپس دسترسی IP را آزمایش کنید:
docker run --rm alpine ping -c 4 1.1.1.1بعد DNS را آزمایش کنید:
docker run --rm alpine ping -c 4 example.comاگر هر دو تست موفق هستند، مسیر خروجی کانتینر و DNS در این آزمایش کار می‌کنند.
جدول تشخیص سریع مشکل
| نشانه | بررسی پیشنهادی |
|---|---|
| Host اینترنت دارد، Container ندارد | Forward، NAT و Firewall |
| IP کار می‌کند ولی Domain نه | DNS کانتینر |
| بعد از مهاجرت به nftables قطع شده | FORWARD policy و Ruleهای قدیمی |
| Docker بعد از reboot بالا نمی‌آید | IP Forwarding و journalctl |
| Published Port در دسترس نیست | Forward، NAT، backend و Firewall Host |
آیا باید کل nftables را Flush کنیم؟
خیر؛ این کار را به‌عنوان راه‌حل عمومی انجام ندهید.
پاک‌کردن کامل Ruleset ممکن است SSH، سرویس‌های عمومی، محدودیت‌های امنیتی و Ruleهای متعلق به برنامه‌های دیگر را تحت تأثیر قرار دهد. روی VPS راه دور، تغییر اشتباه فایروال حتی می‌تواند باعث قطع دسترسی مدیریتی شما شود.
روش بهتر این است که ابتدا Rule ایجادکننده Drop را پیدا کنید، Counterها را بررسی کنید و فقط بخش مرتبط را اصلاح کنید.
اگر برای Docker، Docker Compose، API، سرویس‌های Self-hosted یا محیط آزمایشی به یک سرور مستقل نیاز دارید، VPS لینوکسی امکان کنترل کامل روی Docker daemon، شبکه، Firewall و سرویس‌های سیستم را در اختیار شما قرار می‌دهد. هنگام انتخاب سرور، RAM، CPU، فضای دیسک و ترافیک مورد نیاز کانتینرهای خود را در نظر بگیرید.
برای پروژه‌هایی که محل میزبانی داخل کشور اهمیت دارد، می‌توانید پلن‌های سرور مجازی ایران ایرانیکاسرور را نیز متناسب با نیاز پروژه بررسی کنید.
Docker 29 و backend مستقیم nftables
یک تغییر مهم در نسخه‌های جدید Docker این است که Docker Engine 29 پشتیبانی مستقیم از nftables را ارائه کرده است. این قابلیت در مستندات فعلی Docker همچنان experimental معرفی شده و باید قبل از استفاده در محیط Production محدودیت‌های نسخه دقیق بررسی شود.
در حالت nftables، Docker برای Bridge Network جدول‌های nftables خودش را ایجاد می‌کند. Docker همچنین توصیه می‌کند این جدول‌ها را مستقیماً ویرایش نکنید، زیرا مالکیت و مدیریت آن‌ها بر عهده خود Docker است.
تفاوت مهم دیگر این است که در backend مستقیم nftables، Docker مانند مسیر قبلی لزوماً IP Forwarding را برای شما فعال نمی‌کند. در نتیجه بعد از مهاجرت ممکن است نیاز باشد وضعیت Forwarding میزبان را جداگانه بررسی کنید.
همچنین ساختار DOCKER-USER که در backend مبتنی بر iptables شناخته شده است، در پیاده‌سازی مستقیم nftables به همان شکل وجود ندارد. بنابراین انتقال Ruleهای سفارشی قدیمی باید با شناخت ساختار جدید انجام شود و نباید صرفاً Ruleهای قبلی را کپی کرد.
پرسش‌های متداول
چرا خود Ubuntu اینترنت دارد ولی Docker اینترنت ندارد؟
چون ترافیک کانتینر Bridge از مسیر Forward و NAT میزبان عبور می‌کند. سالم‌بودن OUTPUT خود Host تضمین نمی‌کند ترافیک Forward شده کانتینر نیز مجاز باشد.
آیا nftables با Docker ناسازگار است؟
نه به‌صورت مطلق. Docker در نسخه‌های جدید امکان استفاده مستقیم از nftables را دارد و در حالت معمول نیز سیستم‌های لینوکسی جدید ممکن است از زیرساخت nftables در کنار ابزارهای سازگار استفاده کنند. مشکل بیشتر زمانی رخ می‌دهد که Ruleهای چند سیستم مدیریت فایروال با یکدیگر تداخل داشته باشند یا مهاجرت ناقص انجام شده باشد.
آیا FORWARD را روی ACCEPT قرار دهیم؟
برای تشخیص مشکل در محیط مناسب می‌تواند مفید باشد، اما ACCEPT عمومی را نباید بدون بررسی معماری شبکه به راه‌حل دائمی تبدیل کرد. بهتر است پس از مشخص‌شدن علت، Rule محدود و دقیق ایجاد شود.
آیا خاموش‌کردن UFW مشکل را حل می‌کند؟
ممکن است در یک تست تشخیصی نشان دهد Firewall در مشکل دخیل است، اما خاموش‌کردن دائمی فایروال راه‌حل مناسبی نیست. باید Rule متداخل شناسایی و اصلاح شود.
آیا باید iptables را در Docker غیرفعال کنیم؟
در بیشتر سرورها خیر. جلوگیری از ساخت Ruleهای فایروال توسط Docker بدون ایجاد Ruleهای جایگزین می‌تواند NAT و دسترسی اینترنت شبکه Bridge را مختل کند.
چطور بفهمیم مشکل DNS است یا nftables؟
ابتدا از داخل کانتینر یک IP عمومی مانند 1.1.1.1 را آزمایش کنید. اگر IP پاسخ می‌دهد ولی دامنه resolve نمی‌شود، بررسی DNS اولویت بیشتری دارد. اگر IP هم قابل دسترس نیست، Forward، NAT و Firewall را بررسی کنید.
چرا مشکل بعد از reboot دوباره برمی‌گردد؟
ممکن است تغییر شما موقت بوده باشد یا Ruleset هنگام Boot دوباره از فایل تنظیمات فایروال بارگذاری شود. IP Forwarding نیز اگر فقط با sysctl -w تغییر کرده باشد، برای پایداری بعد از reboot نیازمند تنظیم دائمی متناسب با سیستم است.
جمع‌بندی
قطع اینترنت Docker بعد از تغییر nftables معمولاً با حذف تصادفی Ruleها حل نمی‌شود. مسیر درست این است که ابتدا اینترنت Host و Container را جدا کنید، سپس IP Forwarding، FORWARD policy، NAT، Firewall Backend و قوانین باقی‌مانده از تنظیمات قبلی را بررسی کنید. اگر مشکل بعد از مهاجرت از iptables به nftables ایجاد شده، policy قدیمی DROP در FORWARD یکی از اولین مواردی است که ارزش بررسی دارد.
تماس با ایرانیکاسرور
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)