اتصال امن Docker Swarm با Tailscale VPN؛ بدون IP عمومی و Port Forwarding

  • 0 Comments
  • 38 Views
تجربه واقعی DevOps · راهنمای عملی

سه سرور لینوکسی، سه شبکه متفاوت و یک Docker Swarm؛ بدون IP عمومی، بدون Port Forwarding و بدون اینکه پورت‌های مدیریتی را روی اینترنت باز کنم.

Tailscale VPNDocker SwarmWireGuardZero Trust
خلاصه تجربه: Tailscale برای من جایگزین جادویی امنیت نبود؛ اما پیچیده‌ترین بخش شبکه را از یک پروژه چندروزه به چند نصب ساده تبدیل کرد. نودها IP خصوصی پایدار گرفتند، مستقیماً یکدیگر را دیدند و ترافیک Swarm از یک Mesh رمزنگاری‌شده عبور کرد.

مسئله از Docker نبود؛ از شبکه بود

در آزمایشگاه من یک Linux Mint نقش Manager را داشت، Rocky Linux یک Worker بود و Worker دوم روی Debian و در شبکه‌ای کاملاً متفاوت اجرا می‌شد. Docker روی هر سه ماشین آماده بود؛ اما Swarm بدون یک مسیر قابل‌اعتماد میان نودها شکل نمی‌گیرد.

1ManagerLinux Mint در شبکه محلی
2WorkerRocky Linux پشت NAT
3WorkerDebian در یک شبکه دیگر

Swarm برای مدیریت کلاستر به TCP/2377، برای کشف نودها به TCP و UDP/7946 و برای Overlay Network به UDP/4789 نیاز دارد. بازکردن این پورت‌ها روی اینترنت عمومی—به‌خصوص VXLAN—راه‌حل قابل‌قبولی برای من نبود.

هدف: نودها باید مثل اعضای یک LAN خصوصی با هم صحبت کنند، درحالی‌که هیچ سرویس مدیریتی مستقیماً روی اینترنت دیده نشود.

Tailscale دقیقاً چه کاری انجام می‌دهد؟

Tailscale یک Tailnet خصوصی روی WireGuard می‌سازد. هر دستگاه هویت و IP خصوصی خودش را دارد و در صورت امکان، ارتباط به‌شکل مستقیم و Peer-to-Peer برقرار می‌شود. Tailscale توزیع کلید، NAT Traversal، DNS، معرفی دستگاه‌ها و Access Policy را هماهنگ می‌کند؛ اما محتوای ترافیک مستقیم میان دو نود منتقل می‌شود.

Control Planeهویت، کلیدها، Routeها و Policyها را هماهنگ می‌کند.
Data Planeترافیک واقعی را در تونل WireGuard جابه‌جا می‌کند.
Relayفقط وقتی ارتباط مستقیم ممکن نباشد، DERP یا Peer Relay وارد مسیر می‌شود.

Laptop ───── WireGuard encrypted tunnel ───── Server
        direct when possible · relay when necessary

حتی در حالت Relay، رمزنگاری سرتاسری باقی می‌ماند؛ تفاوت اصلی در Latency و Throughput است.

راه‌اندازی Swarm روی IP خصوصی Tailscale

پس از نصب Tailscale روی هر سه ماشین، اتصال را با tailscale status و tailscale ping بررسی کردم. سپس به Docker گفتم آدرس Tailscale ماشین Manager را به نودهای دیگر معرفی کند.

۱. ایجاد Swarm روی Manager

docker swarm init \
  --advertise-addr <TAILSCALE_MANAGER_IP>

۲. اضافه‌کردن Workerها

docker swarm join \
  --token <WORKER_TOKEN> \
  <TAILSCALE_MANAGER_IP>:2377

۳. بررسی مسیر واقعی ارتباط

tailscale ping swarm-manager-mint
docker node ls
اگر خروجی Tailscale عبارت direct را نشان دهد، دو نود مستقیماً متصل‌اند. نمایش relay به معنی عبور مسیر از DERP است—با رمزنگاری کامل، اما احتمالاً کمی کندتر.

نتیجه‌ای که در عمل گرفتم

  • Port Forwarding از سناریو حذف شد.
  • به IP عمومی ثابت وابسته نبودم.
  • SSH فقط روی شبکه خصوصی در دسترس بود.
  • MagicDNS جای IPهای حفظ‌کردنی را گرفت.
  • نودهای سه شبکه مانند یک LAN رفتار کردند.
  • دسترسی‌ها با ACL و Tag محدود شدند.

برای SSH دو انتخاب داشتم: OpenSSH معمولی روی IP خصوصی Tailscale، یا Tailscale SSH که هویت و Policyهای Tailnet را وارد فرایند مجوزدهی می‌کند.

sudo tailscale set --ssh
ssh sepehr@swarm-manager-mint

Tailscale یا VPN سنتی؟

موضوع VPN سنتی Tailscale
معماری اغلب Gateway مرکزی Mesh و مستقیم در صورت امکان
NAT Traversal تنظیم دستی بیشتر خودکار در بسیاری از شبکه‌ها
مدیریت کلید دستی یا وابسته به سرور بر پایه هویت و دستگاه
DNS داخلی نیازمند تنظیم جداگانه MagicDNS
کنترل دسترسی عمدتاً مبتنی بر شبکه کاربر، دستگاه، Tag و Policy

اگر کنترل کامل روی Gateway و Routeها اولویت اول باشد، VPN سنتی همچنان انتخاب خوبی است. اما برای Homelab، تیم کوچک و زیرساخت پراکنده، Tailscale هزینه عملیاتی بسیار کمتری دارد.

امنیت: بخش مهمی که نباید ساده‌سازی شود

نصب Tailscale به‌تنهایی زیرساخت را Zero Trust نمی‌کند. امنیت واقعی زمانی شکل می‌گیرد که دسترسی‌ها محدود، هویت‌ها قوی و Endpointها به‌روز باشند.

  • Policy پیش‌فرض را بازبینی کنید.
  • برای نقش‌های سرور Tag تعریف کنید.
  • SSH را فقط برای دستگاه مدیریتی باز کنید.
  • MFA را روی Identity Provider فعال کنید.
  • دستگاه‌های قدیمی را از Tailnet حذف کنید.
  • فایروال سیستم‌عامل را همچنان حفظ کنید.
برای Swarm فقط پورت‌های ضروری را بین Tagهای tag:swarm-manager و tag:swarm-worker مجاز کنید. Tailnet خصوصی نباید به معنی «همه به همه» باشد.

Subnet Router چه زمانی مفید است؟

اگر روی یک پرینتر، NAS، روتر یا سیستم قدیمی امکان نصب Tailscale وجود ندارد، یک نود Tailscale می‌تواند مسیر آن Subnet را advertise کند:

sudo tailscale set \
  --advertise-routes=192.168.56.0/24

پس از تأیید Route در پنل مدیریتی، فقط دستگاه‌هایی که Policy اجازه می‌دهد به آن شبکه داخلی دسترسی خواهند داشت.

پرسش‌های متداول

آیا Tailscale به IP عمومی نیاز دارد؟

در بیشتر سناریوها خیر. NAT Traversal ارتباط مستقیم را امتحان می‌کند و در صورت شکست، Relay وارد مسیر می‌شود.

آیا ترافیک همیشه از سرورهای Tailscale عبور می‌کند؟

خیر. در اتصال direct، ترافیک مستقیماً بین دستگاه‌هاست. DERP فقط زمانی استفاده می‌شود که مسیر مستقیم ممکن نباشد.

آیا Tailscale برای Docker Swarm مناسب است؟

برای آزمایشگاه و زیرساخت‌های پراکنده بسیار کاربردی است؛ مشروط به اینکه پورت‌های Swarm و Policyهای دسترسی با دقت طراحی شوند.

تفاوت Tailscale و WireGuard چیست؟

WireGuard پروتکل تونل‌سازی است. Tailscale مدیریت هویت، کلید، Mesh، NAT Traversal، DNS و Policy را روی آن اضافه می‌کند.

جمع‌بندی

ارزش اصلی Tailscale برای من «VPN دیگری» نبود؛ بلکه حذف اصطکاک شبکه بود. سه نود در سه محیط متفاوت، بدون پورت عمومی و بدون مدیریت دستی تونل‌ها، به یک Swarm خصوصی و قابل‌کنترل تبدیل شدند. همین سادگی اجازه داد زمانم را به‌جای روتر و NAT، روی خود زیرساخت صرف کنم.

administrator

Leave A Comment