پیاده‌سازی Micro-segmentation در شبکه با WireGuard و کنترلر پایتون
چرا VPNهای سنتی دیگر امن نیستند؟
در دوران شبکه‌های مدرن و ابری، مدل سنتی دسترسی از راه دور (Remote Access) که مبتنی بر VPNهای لایه ۲ یا ۳ است، با یک چالش امنیتی بزرگ روبروست: اعتمادِ ضمنی. در این مدل، وقتی کاربری به VPN متصل می‌شود، یک IP در رنج شبکه داخلی دریافت کرده و عملاً به بخشی از شبکه تبدیل می‌شود. اگر یک ایستگاه کاری آلوده شود، مهاجم می‌تواند به راحتی در شبکه حرکت عرضی (Lateral Movement) کرده و به سایر سرویس‌ها دسترسی پیدا کند.
پارادایم Zero-Trust (اعتماد صفر) بر این اصل استوار است: «هرگز اعتماد نکن، همیشه تایید کن». در این مقاله، روشی را پیاده‌سازی می‌کنیم که در آن دسترسی‌ها نه بر اساس “اتصال به شبکه”، بلکه بر اساس “هویت کاربر” و “نیاز دسترسی به سرویس خاص” (Micro-segmentation) مدیریت می‌شوند.
معماری سیستم Zero-Trust؛ از احراز هویت تا فایروال هوشمند
معماری پیشنهادی ما از سه لایه اصلی تشکیل شده است:
- لایه Identity/Control Plane: یک کنترلر پایتونی (FastAPI) که وظیفه احراز هویت و صدور سیاست‌های دسترسی را بر عهده دارد.
- لایه Data Plane (WireGuard Gateway): یک گیت‌وی لینوکسی که تونل‌های رمزنگاری شده بسیار سریع را برای کلاینت‌ها برقرار می‌کند.
- لایه Policy Enforcement: استفاده از nftables بر روی گیت‌وی که به ازای هر کلاینت، قوانین دسترسی را به صورت ریزدانه (Granular) اعمال می‌کند.
پیاده‌سازی فنی بخش کنترلر با پایتون و FastAPI
برای پیاده‌سازی، از FastAPI برای مدیریت APIها و کتابخانه‌های استاندارد لینوکس برای تعامل با شبکه استفاده می‌کنیم.
طراحی موتور سیاست‌گذاری (Policy Engine) برای کنترل دسترسی‌ها
ابتدا باید ساختاری برای تعریف دسترسی‌ها داشته باشیم. برای نمونه، دسترسی زیر را در نظر بگیرید:
کاربر A فقط به سرویس دیتابیس (10.20.30.40:5432) دسترسی دارد.
طراحی موتور سیاست‌گذاری (Policy Engine) برای کنترل دسترسی‌ها
مدیریت اتصال کاربران با WireGuard و اعمال قوانین فایروال
کنترلر ما وظیفه دارد به محض اتصال کاربر، کلید عمومی او را ثبت کرده و قوانین فایروال را برای همان IP اختصاصی اعمال کند:
مدیریت اتصال کاربران با WireGuard و اعمال قوانین فایروال
استقرار و راه‌اندازی سیستم با داکر (Docker)
برای اینکه این کنترلر در محیط سرور به راحتی اجرا شود، آن را در یک کانتینر داکر قرار می‌دهیم تا مدیریت پکیج‌ها و وابستگی‌ها ساده‌تر شود.
Dockerfile پیشنهادی:
استقرار و راه‌اندازی سیستم با داکر (Docker)
نکته امنیتی: برای اجرای دستورات wg و nft از داخل کانتینر، کانتینر باید با NET_ADMIN privileges اجرا شود (–cap-add=NET_ADMIN).
فلسفه طراحی امنیتی: چرا سیاست «افت پیش‌فرض» (Default Drop) حیاتی است؟
نشت ترافیک در ZTNA از دو مسیر رخ می‌دهد:
- Fail-open بودن فایروال: اگر کنترلر crash کند، قوانین قبلی باقی بمانند و دسترسی‌های منقضی‌شده باز شوند.
- قانون فراموش‌شده: یک accept قدیمی که برای کاربر حذف‌شده باقی مانده است.
راه‌حل ما:
- Base Chain با سیاست drop روی مسیر forward → هیچ ترافیکی بدون rule صریح عبور نمی‌کند (Fail-closed).
- تمام ruleهای داینامیک فقط در chain مدیریت‌شده inet filter ztna_dynamic قرار می‌گیرند که با یک flush + reload اتمیک بازسازی می‌شود.
- یک Lease TTL در سطح کنترلر → اگر کنترلر قطع شود و lease تمدید نشود، peer از هر دو لایه (WireGuard + nftables) حذف می‌شود.
پیکربندی قواعد پایه فایروال (nftables) برای امنیت گیت‌وی
پیکربندی قواعد پایه فایروال (nftables) برای امنیت گیت‌وی
سه نکته امنیتی حیاتی در این ruleset:
| قانون | جلوی چه تهدیدی را می‌گیرد |
| iifname “wg0” ip saddr != 10.66.0.0/24 drop | Spoofing: یک peer نمی‌تواند با IP قربانی دیگری پکت بفرستد |
| iifname “wg0” oifname “wg0” drop | حرکت عرضی مستقیم کلاینت‌به‌کلاینت در همان تونل |
| policy drop در forward | Fail-closed بودن کل سیستم حتی اگر کنترلر بمیرد |
۳. ماژول مدیریت فایروال (controller/fw_manager.py)
استراتژی اعمال اتمیک: به‌جای افزودن/حذف ruleها یکی‌یکی (که می‌تواند وسط کار قطع شود و ناسازگاری بگذارد)، کنترلر همیشه نسخه کامل و Desired State از ruleها را می‌سازد و با یک تراکنش nft -f از طریق flush chain + insert rules + rename اعمال می‌کند. این همان الگوی Atomic Swap در CI/CD است:
ماژول مدیریت فایروال (controller/fw_manager.py)
ماژول مدیریت فایروال (controller/fw_manager.py)
راه‌اندازی چرخه همگام‌سازی (Reconciliation Loop) در کنترلر
کنترلر یک حلقه هماهنگ‌سازی (Reconciliation Loop) دارد که هر ۳۰ ثانیه، Desired State را از دیتابیس می‌خواند و با State واقعی مقایسه و در صورت لزوم sync می‌کند — دقیقاً مثل Kubernetes Controller:
راه‌اندازی چرخه همگام‌سازی (Reconciliation Loop) در کنترلر
تست عدم نشت (Leak-Tests) با Pytest
تست عدم نشت (Leak-Tests) با Pytest
تست عدم نشت (Leak-Tests) با Pytest
جمع‌بندی؛ پیاده‌سازی شبکه مدرن و امن با معماری Zero-Trust
- Fail-Closed: policy drop در base chain + atomic swap یعنی هیچ حالتی (کرش کنترلر، خطای سینتکس rule، قطع شبکه بین کنترلر و گیت‌وی) منجر به باز شدن دسترسی نمی‌شود.
- Idempotent Reconciliation: Desired State همیشه از دیتابیس rebuild می‌شود؛ پس حتی اگر کسی rule را دستی از فایروال حذف کند، حداکثر ۳۰ ثانیه بعد برگردد.
- Anti-Spoofing + No Lateral Movement: با دو guard دائمی در مسیر forward، حتی if گیت‌وی از سمت WireGuard compromise شود، مهاجم نمی‌تواند خود را به جای دیگری جا بزند یا به کلاینت‌های دیگر برسد.
جمع‌بندی و آینده‌نگری
با استفاده از این روش، شما دیگر نگران حرکت مهاجم در شبکه نخواهید بود. مزایای این رویکرد عبارتند از:
- Micro-segmentation: ایزوله کردن کامل سرویس‌ها از یکدیگر.
- Auditability: کنترلر تمام دسترسی‌ها را لاگ می‌کند.
- Agility: امکان تغییر دسترسی‌ها بدون تغییر در توپولوژی شبکه.
- Performance: استفاده از WireGuard که یکی از سریع‌ترین پروتکل‌های VPN حال حاضر است.
این سیستم در مقایسه با روش‌های سنتی، کنترل کاملی به تیم زیرساخت می‌دهد تا بدون درگیر شدن با تنظیمات پیچیده تجهیزات فیزیکی، Network-as-Code واقعی را در سطح دسترسی‌های کاربران پیاده‌سازی کنند.