در معماری سنتی شبکه لینوکس، کلیه رابط‌های شبکه از یک جدول مسیریابی سراسری مشترک به نام پایگاه داده Forwarding Information Base (FIB) استفاده می‌کنند. در محیط‌های اداری ساده یا سرورهای تک‌کاربره با یک رابط فیزیکی، این ساختار بدون مشکل پاسخگوی نیازهاست.

با این وجود، در گیت‌وی‌های شبکه اختصاصی مجازی (VPN)، مسیریاب‌های مبتنی بر چند ارائه‌دهنده (Multi-WAN) و سامانه‌های چندمستأجره، اشتراک جدول مسیریابی چالش‌های امنیتی بزرگی پدید می‌آورد. هنگامی که رابط‌ها در یک دامنه مسیریابی هم‌پوشانی دارند، تداخل در انتخاب گیت‌وی پیش‌فرض رخ می‌دهد. در صورت قطع ناگهانی تونل رمزنگاری‌شده، ترافیک به سمت رابط‌های فیزیکی ناامن (نظیر Wi-Fi یا اترنت) بازمی‌گردد و بسته‌های رمزنشده به همراه درخواست‌های نام دامنه DNS در شبکه محلی افشا می‌شوند.

در گذشته، مهندسان شبکه برای حل این چالش از فضاهای نام شبکه لینوکس (netns) استفاده می‌کردند. هرچند netns با تکثیر کامل پشته شبکه (شامل سوکت‌ها، رابط‌های loopback، قوانین فایروال و متغیرهای sysctl) ایزولاسیون کاملی فراهم می‌کند، اما سربار منابع بسیار سنگینی به بار می‌آورد. تبادل بسته میان فضاهای نام نیازمند رابط‌های مجازی veth یا برنامه‌های eBPF است که موجب مصرف مکرر حافظه sk_buff و افت عملکرد در خطوط پرسرعت 40GbE و 100GbE می‌گردد.

جهت برقراری ایزولاسیون کامل در سطح کلاس مخابراتی بدون تحمیل هزینه‌های سنگین مجازی‌سازی، هسته لینوکس قابلیت Virtual Routing and Forwarding (VRF) را مبتنی بر زیرسیستم Layer 3 Master Device (l3mdev) معرفی کرد.

+--------------------------------------------------------------------------+
|          معماری تفکیک چندجدولی مسیریابی LINUX VRF و L3MDEV               |
+--------------------------------------------------------------------------+
|                                                                          |
|   +------------------------------------------------------------------+   |
|   |                       برنامه‌های فضای کاربری                      |   |
|   |                                                                  |   |
|   |   +-------------------+                     +----------------+   |   |
|   |   | کلاینت محافظت‌شده |                     | سرویس مدیریتی  |   |   |
|   |   |  (ip vrf exec)    |                     | (SSH / پایش)   |   |   |
|   +---+---------+---------+---------------------+--------+-------+---+   |
|                 | SO_BINDTODEVICE                        |               |
|                 v (vrf-secure)                           v               |
|   +------------------------------------------------------------------+   |
|   |                        پشته شبکه هسته لینوکس                     |   |
|   |                                                                  |   |
|   |   [ دستگاه اصلی VRF: vrf-secure]        [ دامنه عمومی پیش‌فرض    ]|   |
|   |   [ شناسه جدول FIB: 100        ]        [ شناسه جدول FIB: 254    ]|   |
|   |                                                                  |   |
|   |   جستجوی FIB (ایزوله):                  جستجوی FIB (عمومی):      |   |
|   |   default dev riceguard0                default via 192.168.1.1  |   |
|   |   10.8.0.0/24 dev riceguard0            192.168.1.0/24 dev eth0  |   |
|   |             |                                    |               |   |
|   |             |                                    |               |   |
|   |   +---------v---------+                +---------v---------+     |   |
|   |   | رابط زیرمجموعه:   |                | رابط فیزیکی:      |     |   |
|   |   | riceguard0        |                | eth0 (WAN / Wi-Fi)|     |   |
|   |   +---------+---------+                +---------+---------+     |   |
|   +-------------|------------------------------------|---------------+   |
|                 v                                    v                   |
|     +-----------------------+            +-----------------------+       |
|     | تونل رمزنگاری‌شده VPN  |            | خروجی فیزیکی شبکه     |       |
|     | (ایزولاسیون کامل داده)|            | (عدم نشت اطلاعات)     |       |
|     +-----------------------+            +-----------------------+       |
|                                                                          |
+--------------------------------------------------------------------------+

ساختار درونی Linux VRF و زیرسیستم l3mdev

در لینوکس، سازوکار VRF در قالب درایور دستگاه شبکه مجازی پیاده‌سازی شده است (drivers/net/vrf.c). برخلاف فضاهای نام شبکه، دستگاه اصلی VRF تمام پشته را تکثیر نمی‌کند، بلکه تنها نقش یک متصل‌کننده به شناسه مشخصی از جدول مسیریابی FIB در هسته را بر عهده دارد.

رابط‌های شبکه فیزیکی یا مجازی به عنوان دستگاه زیرمجموعه (slave) به دستگاه اصلی VRF متصل می‌شوند. پس از آن، زیرساخت Layer 3 Master Device مسئولیت هدایت بسته‌ها را بر عهده می‌گیرد:

۱. تعیین قلمرو جستجوی FIB در ورودی و خروجی

هنگامی که یک بسته IP به رابط متصل به VRF وارد می‌شود، هسته درایور l3mdev را فراخوانی می‌کند. این درایور جستجوی مسیر را از جدول سراسری به جدول اختصاصی متصل به آن VRF (مانند جدول ۱۰۰) هدایت می‌نماید.

از آنجا که مسیرهای موجود در جدول ۱۰۰ هیچ دسترسی به جدول سراسری ۲۵۴ ندارند، هرگونه نشت مسیر به طور قطعی ناممکن می‌شود:

  • فیلترینگ مسیر برگشتی (rp_filter): بررسی صحت نشانی مبدأ تنها در چارچوب جدول VRF صورت می‌گیرد و بسته‌های جعل‌شده مسدود می‌شوند.
  • الزام در مسیر خروجی: بسته‌های ارسال‌شده توسط برنامه‌های وابسته به VRF امکان خروج از گیت‌وی جدول سراسری را نخواهند داشت.

۲. اتصال سوکت‌ها به دامنه VRF

پردازش‌های سامانه می‌توانند ترافیک شبکه خود را با یکی از سه روش استاندارد زیر به یک VRF معین تخصیص دهند:

۱. گزینه سوکت SO_BINDTODEVICE: برنامه به‌طور صریح سوکت را به نام دستگاه اصلی VRF (مانند vrf-secure) پیوند می‌زند تا کلیه ورودی‌ها و خروجی‌ها تابع جدول آن باشند. ۲. استفاده از Cgroups v2 و دستور ip vrf exec: با بهره‌گیری از قلاب‌های BPF cgroup (cgroup/sock_create)، مدیران سامانه می‌توانند بدون دستکاری کدهای منبع، ساختار پردازش‌ها را درون دامنه VRF اجرا نمایند. ۳. گزینه SO_BINDTOIFINDEX: روشی سبک و با بازده بالا برای اتصال سوکت از طریق شناسه عددی رابط شبکه.

+--------------------------------------------------------------------------+
|            مقایسه فنی: فناوری VRF در برابر فضاهای نام شبکه (NETNS)        |
+--------------------------------------------------------------------------+
| مشخصه معماری           | فناوری VRF (l3mdev)     | فضاهای نام (netns)    |
+------------------------+-------------------------+-----------------------+
| جداسازی جداول مسیریابی | جدول مستقل FIB          | تکثیر کامل پشته شبکه  |
| مصرف حافظه رم          | بسیار ناچیز (<۱۰ کیلوبایت)| قابل توجه (>۱ مگابایت)|
| انتقال بین دامنه‌ها    | در سطح هسته Zero-copy   | سربار ناشی از veth/BPF|
| فضای سوکت‌ها           | مشترک در سراسر سرور     | کاملاً مجزا           |
| مدیریت تنظیمات sysctl  | یکپارچه و متمرکز        | نیازمند تنظیم مکرر    |
| توان عملیاتی خط        | سرعت کامل خطوط ۴۰G-۱۰۰G | افت کارایی زیر بار    |
+--------------------------------------------------------------------------+

مدیریت سرویس‌های گوش‌به‌زنگ با tcp_l3mdev_accept

یکی از مشکلات همیشگی در معماری‌های چندجدولی، مدیریت پردازش‌های گوش‌به‌زنگ (listening daemons) است. در حالت معمول، اگر سرویس DNS محلی (مانند Unbound) یا سرور SSH روی نشانی 0.0.0.0:53 فعال باشد، تنها ترافیک دامنه سراسری را می‌پذیرد و رابط‌های عضو سایر VRFها قادر به برقراری ارتباط با آن نخواهند بود.

هسته لینوکس برای حل این مسئله بدون نیاز به اجرای نمونه‌های متعدد از سرویس‌ها، تنظیمات sysctl کاربردی را فراهم آورده است:

# پذیرش اتصالات TCP از تمامی VRFها توسط سرویس‌های سراسری
sysctl -w net.ipv4.tcp_l3mdev_accept=1

# پذیرش بسته‌های UDP از تمامی VRFها توسط سرویس‌های سراسری
sysctl -w net.ipv4.udp_l3mdev_accept=1

با فعال‌سازی tcp_l3mdev_accept، بسته TCP SYN دریافتی از رابط VRF با سوکت شنونده سراسری مطابقت پیدا می‌کند. در حین ایجاد سوکت فرزند، هسته آن را به دستگاه VRF رابط ورودی متصل می‌سازد. از این رو، کلیه پاسخ‌ها از مسیر صحیح برگردانده شده و مانع بروز مسیریابی نامتقارن می‌گردد.

راهنمای گام‌به‌گام: راه‌اندازی گیت‌وی ایمن VPN با VRF

پیکربندی VRF در لینوکس از طریق ابزارهای بسته iproute2 انجام می‌گیرد:

گام نخست: ایجاد دستگاه اصلی VRF

ساخت رابط شبکه مجازی vrf-vpn متصل به جدول مسیریابی شماره ۱۰۰:

# ایجاد دستگاه VRF با اتصال به جدول ۱۰۰
ip link add dev vrf-vpn type vrf table 100

# فعال‌سازی رابط دستگاه اصلی
ip link set dev vrf-vpn up

گام دوم: الحاق رابط‌های تونل و شبکه داخلی

قرار دادن رابط تونل (riceguard0) و شبکه کلاینت (vlan20) تحت مدیریت vrf-vpn:

# الصاق رابط‌ها به vrf-vpn
ip link set dev riceguard0 master vrf-vpn
ip link set dev vlan20 master vrf-vpn

# روشن کردن رابط‌های تابعه
ip link set dev riceguard0 up
ip link set dev vlan20 up

گام سوم: مقداردهی جدول مسیریابی ایزوله

تعریف مسیرهای لازم صرفاً در جدول ۱۰۰:

# تعریف زیرشبکه تونل VPN
ip route add 10.8.0.0/24 dev riceguard0 table 100

# تعریف زیرشبکه محلی کلاینت‌ها
ip route add 192.168.20.0/24 dev vlan20 table 100

# تعیین گیت‌وی پیش‌فرض منحصراً از طریق تونل رمزنگاری‌شده
ip route add default dev riceguard0 table 100

گام چهارم: اعتبارسنجی ایزولاسیون و پایش

آزمایش پایداری ارتباط محدود به دامنه vrf-vpn:

# مشاهده مسیرهای جدول ۱۰۰
ip route show table 100

# بررسی پینگ در دامنه VRF
ip vrf exec vrf-vpn ping -c 3 10.8.0.1

# اطمینان از دست‌نخوردن جدول اصلی سیستم
ip route show table main

در صورت قطع تونل riceguard0، ترافیک درون جدول ۱۰۰ به علت نبود مسیر خروجی مستقیماً در هسته متوقف می‌شود. از آنجا که رابط فیزیکی eth0 در جدول سراسری قرار دارد، داده‌های کاربران هرگز بدون رمزنگاری در شبکه محلی نشت نخواهد کرد.

تعامل معماری با RiceGuard و زیرساخت VPNRice

در گیت‌وی‌های تجاری VPNRice، موتور اختصاصی RiceGuard با ابزارهای Linux VRF و l3mdev ترکیب شده و شاخص‌های امنیتی بالایی را تثبیت می‌کند:

۱. جلوگیری قطعی از نشت DNS: سیستم‌عامل‌ها معمولاً درخواست‌های DNS را روی کلیه رابط‌ها منتشر می‌کنند. با قرار دادن رابط RiceGuard و ریزالور درون یک VRF مجزا، امکان خروج پرس‌وجوها روی رابط فیزیکی Wi-Fi منتفی می‌گردد. ۲. مسیریابی خطی Multi-WAN بدون افت سرعت: سرورها هزاران اتصال هم‌روند را در دامنه‌های تفکیک‌شده بدون نیاز به کپی مجدد داده‌ها در حافظه هدایت می‌کنند. ۳. جداسازی کامل صفحه مدیریت سرور: پورت‌های نظارتی و نگهداری (مانند SSH و ابزارهای تله‌متری) در یک VRF مستقل قرار می‌گیرند و از سمت تونل‌های کاربران کاملاً غیرقابل دسترسی هستند.

توصیه‌های اجرایی و الزامات نگهداری

در استقرار عملیاتی این معماری رعایت نکات زیر توصیه می‌شود:

  • فعال‌سازی فیلترینگ سخت‌گیرانه مسیر: تنظیم net.ipv4.conf.all.rp_filter=1 برای ممانعت از جعل نشانی میان دامنه‌ها.
  • قوانین متمرکز فایروال: استفاده از عبارات iifname و oifname روی دستگاه اصلی VRF در ابزار nftables جهت اعمال سیاست‌های حفاظتی یکپارچه.
  • پایش جدول اتصالات (conntrack): با توجه به اشتراک جدول conntrack میان تمامی VRFها، افزایش سقف nf_conntrack_max ضروری است.

به‌کارگیری Linux VRF در کنار l3mdev تعادل استانداردی میان تفکیک بی‌نقص اطلاعات و سرعت حداکثری ارتباطات رقم زده و ساختاری قابل اطمینان برای گیت‌وی‌های مدرن VPN ارائه می‌دهد.