پورت داخل container، پورت host و نام سرویس سه موضوع جدا هستند. امشب شبکهٔ user-defined می‌سازیم و ارتباط داخلی را بدون بازکردن سرویس روی همهٔ NICهای میزبان بررسی می‌کنیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۵ در ۶۰ شب است.

جایگاه در دوره: هدف‌های 352.3 آزمون 305-300.

محیط: docker-a، image lab305-web:v1 شب ۴۳؛ subnet 172.28.5.0/24 آزاد، web305 قبلی حذف شده. ابتدا route و networkهای موجود را ببین.

ip route
sudo docker network ls
sudo docker network create --subnet 172.28.5.0/24 lab305-net
sudo docker run --name web305 --network lab305-net -d \
  -p 127.0.0.1:18050:8080 lab305-web:v1
sudo docker run --rm --network lab305-net alpine:3.23 \
  wget -qO- http://web305:8080/
curl --fail http://127.0.0.1:18050/
sudo docker network inspect lab305-net
sudo docker port web305

DNS داخلی شبکهٔ user-defined نام container را resolve می‌کند؛ client داخل شبکه به 8080 وصل می‌شود. 18050 قرارداد host است. loopback داخل container خود آن container است، نه host یا همسایه.

bridge پیش‌فرض، host network، none و overlay رفتار یکسان ندارند. host namespace شبکه را مشترک می‌کند؛ none مسیر معمول خروجی نمی‌دهد؛ overlay برای ارتباط چندnode نیاز به orchestration و شبکهٔ زیرساخت دارد.

مرز فایروال#

Docker ruleهای forward/NAT خودش را مدیریت می‌کند. فقط دیدن rule INPUT در ufw تضمین سیاست published port نیست. از client مدیریت بیرونی بررسی کن که 18050 روی IP میزبان باز نشده باشد. در releaseهای قدیمی، loopback publishing محدودیت امنیتی داشته است؛ engine را به release اصلاح‌شده به‌روزرسانی و آزمون بیرونی را تکرار کن، بدون flush کردن ruleهای daemon.

تمرین: container client روی شبکهٔ دیگری بساز؛ شکست resolve/connect را با inspect route/network توضیح بده. عضویت در network مجوز application authentication نیست.

بازگشت: ابتدا web305 را stop/rm کن؛ سپس شبکهٔ بدون endpoint را حذف کن. برای درس‌های بعد image را نگه دار. حذف bridge kernel با ip link، جای docker network rm نیست.

منبع: bridge network ، port publishing و محدودیت نسخه ، packet filtering .