مقایسه Linux IPVLAN و MACVLAN: جداسازی با کارایی بالا در درگاه‌های VPN

سرویس‌های کانتینری و مجازی‌سازی چندمستأجره (multi-tenant) استاندارد کنونی در زیرساخت‌های لبه شبکه سازمانی به شمار می‌روند. هنگام میزبانی درگاه‌های گسترده VPN—جایی که سازمان‌های گوناگون یا کارمندان نیازمند حوزه‌های مسیریابی مستقل هستند—مهندسان ترافیک را از طریق فضاهای نام شبکه لینوکس (netns) تفکیک می‌کنند.

با این وجود، مکانیزمی که این فضاهای نام ایزوله را به کارت‌های شبکه فیزیکی (NIC) متصل می‌کند، ظرفیت نهایی سرور را مشخص می‌سازد. پلتفرم‌های سنتی کانتینر، فضاهای نام را از طریق جفت‌های اترنت مجازی (veth) متصل به پل‌های نرم‌افزاری (br0) شبکه می‌کنند. زیر بار ترافیکی چندگیگابیتی، این معماری سنتی موجب اتلاف توان پردازنده، دو بار گردش بسته در پشته شبکه و جهش در تاخیر انتهای توزیع (p99) می‌گردد.

برای رفع این افت کارایی، هسته لینوکس دو فناوری رابط پیشرفته با نام‌های MACVLAN و IPVLAN را توسعه داده است. درک کارکرد فنی این دو درایور به معماران شبکه امکان می‌دهد درگاه‌های کانتینری VPN با توان تبادل خطی بالا و بدون تضعیف جداسازی رمزنگاری‌شده برپا سازند.

---

Container Networking Bottlenecks: هزینه عملکردی استفاده از اترنت مجازی (VETH)

در ساختار استاندارد شبکه کانتینری، بسته‌ها مسیر پرپیچ‌وخمی را میان کارت شبکه فیزیکی و سرویس VPN درون کانتینر طی می‌نمایند:

1. گذر از مرز فضای نام: بسته خروجی کانتینر از طریق یک سوی جفت veth (رابط eth0 درون فضای نام) به بیرون فرستاده می‌شود.
2. جابه‌جایی زمینه پردازش: هسته لینوکس بسته را گرفته و زمینه اجرا را به فضای نام اصلی میزبان که انتهای دیگر جفت (vethXXXX) در آن قرار دارد منتقل می‌کند.
3. هدایت توسط پل نرم‌افزاری: رابط میزبان بسته را به پل نرم‌افزاری (br0) تحویل می‌دهد. پل، آدرس‌های فیزیکی MAC را ارزیابی کرده، جدول پایگاه داده فورواردینگ (FDB) را به‌روزرسانی نموده و فرآیند درخت پوشا را اعمال می‌دارد.
4. ارسال به کارت شبکه فیزیکی: در نهایت، پل بسته را به درگاه فیزیکی (eth0) روانه کرده که خود نیازمند گردش دوباره در کنترل ترافیک (tc) و بافرهای حلقوی است.

معماری سنتی جفت‌های VETH و پل نرم‌افزاری (دو بار گردش کامل در پشته شبکه):

[ فضای نام کانتینر ]
          │
  (eth0: پایانه veth)
          │
[ فضای نام میزبان ]
          ▼
   (vethXXXX متناظر)
          │
          ▼
[ پل نرم‌افزاری: br0 ] ──► (جستجوی FDB، یادگیری MAC، رقابت قفل‌ها)
          │
          ▼
[ کارت فیزیکی: eth0 ] ──► خط انتقال فیزیکی

این زنجیره طولانی اتلاف توان محسوسی بر جای می‌گذارد:

• پردازش دوباره پشته شبکه: هر بسته ناچار است توابع netif_rx() و dev_queue_xmit() را دو نوبت طی کند که دستورات پردازشی هر بسته را دو برابر می‌سازد.
• رقابت قفل در پل نرم‌افزاری: پل‌های شبکه لینوکس از قفل‌های چرخشی برای محافظت از جدول آدرس‌های فیزیکی استفاده می‌کنند. با رسیدن حجم بسته‌ها به چندین میلیون در ثانیه، این رقابت بازدهی را به شدت می‌کاهد.
• تخریب کش پردازنده: جابه‌جایی بافرهای سوکت (sk_buff) میان کارت‌های مجازی، ساختار کش محلی L1/L2 را پاک کرده و ترافیک گذرگاه حافظه را بالا می‌برد.

---

MACVLAN Architecture: آدرس‌های فیزیکی اختصاصی و حذف پل مجازی

فناوری MACVLAN که از نسخه ۲.۶.۲۳ به لینوکس افزوده شد، پل نرم‌افزاری را به کلی حذف می‌کند. MACVLAN به جای ساخت سیم‌های مجازی، چندین زیررابط را مستقیماً روی بستر کارت شبکه فیزیکی اصلی (نظیر eth0) تعریف می‌نماید.

هر زیررابط MACVLAN دارای یک آدرس فیزیکی MAC مستقل و ویژه است. هنگامی که این کارت به یک فضای نام شبکه منتقل می‌شود، همانند یک کارت شبکه سخت‌افزاری مجزا عمل می‌کند.

1. حالت‌های عملیاتی MACVLAN (شامل Bridge، VEPA، Private، Passthru)

چهار حالت عملکردی برای درایور MACVLAN وجود دارد:

• حالت Private: زیررابط قادر نیست با سایر رابط‌های MACVLAN روی کارت مشترک تبادل داده داشته باشد. تمام ترافیک باید مستقیماً از خطوط فیزیکی خارج گردد. مناسب‌ترین انتخاب برای ایزولاسیون کامل ترافیک مشترکین.
• حالت VEPA (Virtual Ethernet Port Aggregator): رابط‌ها فقط در شرایطی با یکدیگر ارتباط برقرار می‌سازند که سوئیچ فیزیکی بالادست از حالت بازتابی (hairpin) برای برگشت بسته‌ها به همان پورت پشتیبانی نماید.
• حالت Bridge: رابط‌ها مستقیماً از طریق یک سوئیچ لایه دوم فوق‌العاده سبک درون هسته با هم تبادل داده می‌کنند. این سازوکار نیاز به سوئیچ فیزیکی را رفع کرده و بسیار سبک‌تر از پل‌های نرم‌افزاری قدیمی لینوکس است.
• حالت Passthru: کنترل مطلق و انحصاری پورت فیزیکی را به یک رابط کانتینری اختصاص می‌دهد که برای ارتباطات بسیار پرسرعت به کار می‌رود.

2. معضل سقف مجاز آدرس‌های MAC: امنیت پورت سوئیچ‌ها و شبکه Wi-Fi

با وجود سرعت بسیار بالا به دلیل حذف پل‌ها، ساختار MACVLAN با دو چالش روبرو می‌شود:

1. تکمیل ظرفیت جداول سخت‌افزاری سوئیچ: از آنجا که هر کارت MACVLAN یک آدرس MAC مستقل منتشر می‌سازد، راه‌اندازی صدها درگاه VPN روی یک سرور سبب اشباع جداول حافظه CAM سوئیچ‌های فیزیکی می‌گردد. سوئیچ‌های سازمانی مجهز به امنیت پورت (Port Security) در صورت مشاهده چندین MAC روی یک درگاه، پورت را قطع می‌نمایند.
2. عدم انطباق با شبکه‌های Wi-Fi: استاندارد ارتباط بی‌سیم IEEE 802.11 استفاده از چند آدرس MAC را برای یک اتصال کلاینت ممنوع کرده است. در نتیجه MACVLAN روی لپ‌تاپ‌ها یا درگاه‌های بی‌سیم کاربرد ندارد.

---

IPVLAN Mechanics: هویت اشتراکی لایه ۲ و مسیریابی لایه ۳

جهت عبور از محدودیت‌های MACVLAN، هسته لینوکس از نسخه ۳.۱۹ درایور IPVLAN را عرضه نمود. IPVLAN به جای اختصاص آدرس‌های مجزای MAC، تنها از یک آدرس MAC متعلق به کارت فیزیکی برای تمامی زیررابط‌ها استفاده می‌کند.

تفکیک بسته‌های ورودی به کانتینرها بر اساس آدرس فیزیکی انجام نشده، بلکه با ارزیابی آدرس IP مقصد در لایه ۳ (Layer 3) صورت می‌پذیرد.

معماری IPVLAN (یک آدرس MAC مشترک، مسیریابی بر مبنای IP مقصد):

[ فضای نام VPN الف ]           [ فضای نام VPN ب ]
  (ipv0: 10.0.1.2)              (ipv1: 10.0.1.3)
         │                              │
         └──────────────┬───────────────┘
                        │
            [ درایور مرکزی IPVLAN ]
 (MAC مشترک: 52:54:00:12:34:56، هدایت بر پایه IP)
                        │
                        ▼
            [ کارت فیزیکی: eth0 ] ──► خط انتقال فیزیکی

1. بررسی حالت‌های IPVLAN L2 و IPVLAN L3

درایور IPVLAN در دو ساختار بنیادین قابل راه‌اندازی است:

• حالت IPVLAN L2: مشابه یک سوئیچ لایه دو رفتار می‌کند. زیررابط‌ها در همان ساب‌نت کارت فیزیکی قرار دارند و بسته‌های برودکست (نظیر ARP و NDP) به کانتینرها ارسال می‌شوند. سوئیچ بیرونی تنها یک آدرس MAC می‌بیند که سبب انطباق کامل با ضوابط شبکه می‌گردد.
• حالت IPVLAN L3: رابط فیزیکی را به یک مسیریاب لایه ۳ درونی بدل می‌سازد. در این حالت پردازش بسته‌های همگانی و درخواست‌های ARP حذف می‌گردد. کانتینرها باید در ساب‌نت‌های مستقل قرار گیرند. با حذف بار ناشی از بسته‌های برودکست، حالت L3 بیشترین بهره‌وری را برای درگاه‌های پرتراکم VPN به ارمغان می‌آورد.

2. فایروال‌های دارای وضعیت و رهگیری اتصالات در حالت L3S

در نسخه‌های اولیه IPVLAN L3، ترافیک بدون برخورد با جدول رهگیری اتصالات فایروال میزبان (conntrack) تبادل می‌شد که امکان اعمال قواعد جامع فایروال را دشوار می‌ساخت.

لینوکس ۴.۱۵ حالت IPVLAN L3S (Symmetric) را ارائه داد. در این حالت ترافیک ورودی و خروجی پیش از رسیدن به کانتینر از قلاب‌های netfilter میزبان گذر می‌کند و اعمال سیاست‌های امنیتی کامل (iptables / nftables) و ترجمه آدرس NAT بدون نیاز به پل مجازی میسر می‌شود.

---

بررسی کارایی و تفکیک امنیتی: مقایسه VETH در برابر MACVLAN و IPVLAN

جدول زیر تفاوت‌های ساختاری میان روش‌های گوناگون جداسازی شبکه را تشریح می‌نماید:

---

پیکربندی عملیاتی: پیاده‌سازی IPVLAN برای فضاهای نام VPN

راه‌اندازی فضای نام پرسرعت برای اتصال تونل‌های VPN با استفاده از IPVLAN در حالت L3 توسط ابزارهای iproute2 انجام می‌پذیرد:

# گام نخست: ایجاد فضای نام شبکه برای درگاه اختصاصی مشترک
sudo ip netns add vpn-tenant-alpha

# گام دوم: افزودن زیررابط IPVLAN روی پورت eth0 در حالت L3
sudo ip link add link eth0 name ipv0 type ipvlan mode l3

# گام سوم: انتقال کارت مجازی به فضای نام تعیین‌شده
sudo ip link set dev ipv0 netns vpn-tenant-alpha

# گام چهارم: تنظیم آدرس آی‌پی در داخل فضای نام
sudo ip -n vpn-tenant-alpha addr add 10.200.1.2/24 dev ipv0
sudo ip -n vpn-tenant-alpha link set dev ipv0 up
sudo ip -n vpn-tenant-alpha link set dev lo up

# گام پنجم: مشخص‌سازی مسیر خروجی پیش‌فرض
sudo ip -n vpn-tenant-alpha route add default dev ipv0

# گام ششم: بررسی برقراری اتصال بدون نیاز به پل مجازی
sudo ip netns exec vpn-tenant-alpha ip addr show dev ipv0

برای اعمال فایروال‌های دارای وضعیت، کافی است گزینه mode l3s در زمان ساخت درج گردد:

sudo ip link add link eth0 name ipv0 type ipvlan mode l3s

---

معماری RiceGuard: جداسازی چندمستأجره با تراکم بالا

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

سامانه RiceGuard برای دستیابی به نهایت تراکم و پایداری، فناوری IPVLAN در حالت L3/L3S را به کار گرفته است:

/* آماده‌سازی خودکار درگاه کانتینری در هسته RiceGuard */
int provision_tenant_ipvlan_interface(const char *parent_dev, const char *child_dev, 
                                      int netns_fd, int l3s_mode) {
    /* تنظیم حالت درایور: IPVLAN_MODE_L3 یا IPVLAN_MODE_L3S */
    uint16_t mode = l3s_mode ? IPVLAN_MODE_L3S : IPVLAN_MODE_L3;
    
    /* صدور درخواست سیستمی Netlink جهت ایجاد کارت بدون کپی حافظه */
    if (netlink_create_ipvlan(parent_dev, child_dev, mode) < 0) {
        perror("netlink_create_ipvlan");
        return -1;
    }

    /* ارسال رابط مجازی ایجاد شده به فضای نام مربوط به مشترک */
    return netlink_move_device_to_netns(child_dev, netns_fd);
}

با استقرار IPVLAN L3، هر کانتینر RiceGuard درون یک فضای نام کاملاً مستقل با جدول مسیریابی و فایروال مجزا عمل می‌کند. داده‌ها بدون هیچ پل مجازی و بدون مصرف آدرس‌های مازاد MAC، با تاخیری کمتر از یک میلی‌ثانیه میان سوکت‌های WireGuard و کارت شبکه فیزیکی به حرکت درمی‌آیند.