سرورهای واسط VPN و گره‌های امنیتی مرزی با ظرفیت بالا به‌طور هم‌زمان دو گروه متمایز از ترافیک شبکه را هدایت می‌کنند: ترافیک خاتمه محلی (شامل تونل‌های رمزنگاری‌شده WireGuard یا IPsec که به سوکت‌های محلی سرور تحویل داده می‌شوند) و ترافیک انتقالی عبوری (بسته‌های رمزگشایی‌شده کاربران که برای خروج به سمت شبکه گسترده WAN از رابط‌های شبکه عبور می‌کنند). در پشته شبکه لینوکس، نحوه مدیریت مسیر میان دسته‌بندی اولیه بسته و جستجو در جدول مسیریابی مستقیماً توان مقیاس‌پذیری سامانه را تعیین می‌کند.

سازوکار IP Early Demux (ip_early_demux) با هدف حذف جستجوهای مکرر در درخت اطلاعات ارسال (FIB Trie) برای اتصالات فعال به هسته لینوکس افزوده شد. با این حال، در سیستم‌هایی که هم‌زمان وظیفه خاتمه محاسبات رمزنگاری و هدایت حجم عظیمی از داده‌های عبوری را بر عهده دارند، پیکربندی Early Demux نیازمند ارزیابی دقیق توازن ساختاری آن است.


چالش مسیریابی: جستجو در درخت FIB در برابر کش سوکت

برای درک اهمیت IP Early Demux، باید مسیر استاندارد یک بسته ورودی IPv4 را پس از دریافت از درایور کارت شبکه (NIC) بررسی کرد:

  1. دریافت اولیه بسته: بسته از طریق تابع ip_rcv() وارد لایه سوم شبکه شده و به ip_rcv_finish_core() انتقال می‌یابد.
  2. جستجوی پیش‌فرض مسیر: هسته لینوکس بلافاصله تابع ip_route_input_noref() را جهت بررسی درخت FIB trie فرامی‌خواند. این ساختار آدرس مقصد، مبدا، نشانه‌های سیاست مسیریابی (fwmark) و رابط ورودی را می‌سنجد تا مشخص کند بسته متعلق به پردازش محلی است (RTN_LOCAL) یا باید به مقصدی دیگر هدایت شود (RTN_UNICAST).
  3. تفکیک و ارسال به سوکت: اگر نتیجه مسیر RTN_LOCAL باشد، مدیریت پردازش به ip_local_deliver() منتقل می‌شود. در این بخش، پروتکل انتقال (TCP یا UDP) در جدول درهم‌سازی سوکت‌ها به جستجو می‌پردازد تا ساختار struct sock مقصد را پیدا کند.
[ بسته ورودی IPv4 ]
          │
          ▼
[ مسیر کلاسیک: ip_rcv_finish_core() ]
          │
          ▼
[ جستجو در درخت FIB Trie: ip_route_input_noref() ] ──► (مصرف دوره‌های پردازنده)
          │
          ├─► مقصد محلی (RTN_LOCAL) ──► ip_local_deliver() ──► جستجوی جدول سوکت
          └─► هدایت عبوری (RTN_UNICAST) ──► ip_forward()

در گیت‌وی پرظرفیتی که ۵ میلیون بسته در ثانیه را از میان هزاران تونل فعال هدایت می‌کند، بررسی کامل درخت FIB برای تک‌تک بسته‌ها بار سنگینی بر حافظه تحمیل کرده و موجب تخلیه مکرر کش‌های سطح دو و سه پردازنده (L2/L3) می‌شود.


سازوکار معماری: نحوه عملکرد میانبر Early Demux

قابلیت IP Early Demux این روال را برای جریان‌های ارتباطی فعال دگرگون می‌سازد. هسته سیستم پیش از مراجعه به ساختار سنگین FIB، مستقیماً از داخل تابع ip_rcv_finish_core() اقدام به پیش‌بینی و یافتن سوکت هدف می‌نماید.

[ بسته ورودی IPv4 ]
          │
          ▼
[ مسیر Early Demux: ip_rcv_finish_core() ]
          │
          ▼
[ بررسی زودهنگام سوکت: tcp_v4_early_demux() / udp_v4_early_demux() ]
          │
          ├─► یافتن سوکت منطبق (sk->sk_rx_dst معتبر است):
          │         │
          │         ├─► انتساب مستقیم مقصد ذخیره‌شده (skb_dst_set_noref)
          │         └─► هدایت مستقیم به ip_local_deliver() [صرف‌نظر از درخت FIB]
          │
          └─► عدم انطباق با سوکت محلی:
                    │
                    └─► بازگشت به مسیر پیش‌فرض ip_route_input_noref()

در هسته لینوکس (net/ipv4/ip_input.c)، روال کنترل Early Demux توابع تخصصی پروتکل‌ها را فرامی‌خواند:

/* ساختار مفهومی در فایل net/ipv4/ip_input.c */
static int ip_rcv_finish_core(struct net *net, struct sock *sk,
                             struct sk_buff *skb, struct net_device *dev,
                             const struct sk_buff *hint)
{
    const struct iphdr *iph = ip_hdr(skb);

    if (net->ipv4.sysctl_ip_early_demux && !skb_dst(skb)) {
        const struct net_protocol *ipprot;
        int protocol = iph->protocol;

        ipprot = rcu_dereference(inet_protos[protocol]);
        if (ipprot && ipprot->early_demux)
            ipprot->early_demux(skb);
    }

    /* در صورت تعیین مقصد توسط early_demux، مرحله بررسی FIB انجام نمی‌شود */
    if (!skb_dst(skb)) {
        int err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
                                      iph->tos, dev);
        if (unlikely(err))
            goto drop;
    }
    return NET_RX_SUCCESS;
}

کارکرد کش مسیر دریافت (sk_rx_dst)

با برقراری ارتباط در پروتکل TCP یا هنگامی که سوکت‌های UDP در حالت متصل به کار گرفته می‌شوند (با فراخوانی connect())، هسته مشخصات مسیر ورودی را در متغیر sk->sk_rx_dst نگهداری می‌کند.

حین اجرای تابع tcp_v4_early_demux()، سیستم چهارمشخصه اتصال را از سرآیند دریافت کرده، سوکت مربوطه را می‌یابد و سلامت مقدار sk->sk_rx_dst را بررسی می‌کند. اگر این مقدار معتبر باشد، مرجع با تابع skb_dst_set_noref(skb, dst) به بسته پیوست می‌شود. در نتیجه، بسته بدون اتلاف زمان در جداول مسیریابی به لایه بالاتر ارسال می‌گردد.


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

اگرچه Early Demux دستاوردهای چشمگیری در افزایش توان ترافیک ورودی به ارمغان می‌آورد، اما در گیت‌وی‌های چندمنظوره نکات مهمی وجود دارد:

  • جستجوهای ناموفق برای ترافیک عبوری: هنگامی که گیت‌وی داده‌های رمزگشایی‌شده کاربران را به سمت شبکه‌های خارجی ارسال می‌کند، این بسته‌ها مقصد محلی ندارند. در صورت روشن بودن Early Demux، سیستم برای تمام بسته‌ها ابتدا جدول سوکت‌ها را می‌کاود که همواره به نتیجه نرسیده و ناچاراً به مسیر FIB بازمی‌گردد.
  • تغییرات پویای مسیرهای چندگانه: در زمان تغییر مسیرهای ECMP، اطلاعات ذخیره‌شده در sk_rx_dst ممکن است برای لحظاتی بسته را به مسیر پیشین بفرستد تا زمانی که سوکت وضعیت مسیر را مجدداً تصدیق نماید.
+-------------------------------------------------------------------------+
|                  سناریوهای عملیاتی در سرورهای VPN                       |
+-------------------------------------------------------------------------+
| سناریوی اول: گره خاتمه‌دهنده تونل امن (ورودی‌های RiceGuard)            |
| -> بسته‌ها به سوکت‌های محلی تحویل داده می‌شوند (جریان‌های UDP)           |
| -> راه‌حل بهینه: فعال‌سازی ip_early_demux و udp_early_demux             |
|                                                                         |
| سناریوی دوم: مسیریاب هدایت داده و گیت‌وی NAT عبوری                      |
| -> بسته‌ها صرفاً میان رابط‌های شبکه در حال جابه‌جایی هستند              |
| -> راه‌حل بهینه: غیرفعال‌سازی ip_early_demux جهت حذف جستجوهای بی‌اثر   |
+-------------------------------------------------------------------------+

راهنمای پیکربندی و بهینه‌سازی Early Demux در لینوکس

مدیران سیستم می‌توانند با تنظیم متغیرهای sysctl این قابلیت را به‌طور کلی یا به تفکیک پروتکل مدیریت کنند.

۱. ارزیابی مقادیر جاری سامانه

بررسی پارامترهای فعال بر روی سرور:

# مشاهده متغیرهای فعال Early Demux
sysctl net.ipv4.ip_early_demux
sysctl net.ipv4.tcp_early_demux
sysctl net.ipv4.udp_early_demux

۲. تنظیم برای سرورهای متمرکز بر خاتمه تونل

روی سرورهایی که کارکرد عمده آنها دریافت و پردازش تونل‌های رمزگذاری‌شده است (نظیر نودهای RiceGuard با میلیون‌ها فریم ورودی UDP)، فعال‌سازی هر دو لایه توصیه می‌شود:

# فعال‌سازی کلی ویژگی
sysctl -w net.ipv4.ip_early_demux = 1

# فعال‌سازی برای TCP (درگاه‌های مدیریتی و سرویس‌های وب)
sysctl -w net.ipv4.tcp_early_demux = 1

# فعال‌سازی برای UDP (سوکت‌های تونل متصل)
sysctl -w net.ipv4.udp_early_demux = 1

جهت تثبیت دائمی پیکربندی پس از راه‌اندازی مجدد سرور، تنظیمات را در فایل /etc/sysctl.d/99-early-demux.conf ذخیره کنید:

cat << 'EOF' > /etc/sysctl.d/99-early-demux.conf
net.ipv4.ip_early_demux = 1
net.ipv4.tcp_early_demux = 1
net.ipv4.udp_early_demux = 1
EOF
sysctl --system

۳. تنظیم برای گیت‌وی‌های صرفاً انتقال داده و مسیریاب‌های NAT

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

# غیرفعال‌سازی در گره‌های انتقال داده خالص
sysctl -w net.ipv4.ip_early_demux = 0

۴. رصد اثربخشی کش با استفاده از nstat

بررسی آماری میزان هم‌پوشانی و موفقیت جستجوهای زودهنگام با ابزار nstat:

# پایش تطابق سوکت زودهنگام و وضعیت بسته‌های مسیریابی
nstat -az | grep -E "IpEarlyDemux|IpInReceives|IpForwDatagrams"

مقایسه شاخص‌های کلیدی: وضعیت فعال در برابر غیرفعال

بازدهی فعال‌سازی Early Demux مستقیماً به الگوی هدایت بسته‌ها بستگی دارد:

معیار ارزیابی Early Demux فعال (سوکت محلی) Early Demux غیرفعال (مسیر پیش‌فرض) Early Demux روی سرور عبوری
میزان بار روی FIB Trie برای ارتباطات جاری حذف می‌شود برای تک‌تک بسته‌ها اجرا می‌شود بررسی FIB همراه با خطای جستجو
اشغال حافظه کش L2/L3 متمرکز روی جدول درهم‌سازی سوکت پراکنده در گره‌های درخت مسیر افزایش بار ناشی از دو مرحله بررسی
نرخ بسته‌ها (PPS) ۷.۸ میلیون در ثانیه پایدار ۵.۹ میلیون در ثانیه پایدار افت اندک توان پردازشی (حدود ۴٪)
تاخیر انتقال داده مشابه حالت پایه (با مراجعه به FIB) قطعی و پایدار افزایش ۳ تا ۵ درصدی تاخیر بسته‌ها
خطر ناهمگامی مسیر ناچیز (به‌دلیل اعتبارسنجی مقصد) کاملاً صفر (محاسبه بلادرنگ مسیر) صفر (عدم وجود سوکت همسان)

پیاده‌سازی تفکیک‌شده در معماری امن RiceGuard

در بستر سرورهای شبکه VPNRice، گره‌های فناوری RiceGuard مسیرهای پردازش را بر اساس ساختار وظایف تفکیک می‌کنند:

  1. رابط‌های ورودی شبکه WAN: درگاه‌های متصل به اینترنت که فریم‌های رمزنگاری‌شده کاربران را می‌پذیرند با مقادیر net.ipv4.ip_early_demux = 1 و net.ipv4.udp_early_demux = 1 عمل می‌کنند. بسته‌ها به محض ورود به سوکت‌های فعال تخصیص یافته و بدون تاخیر مسیریابی روانه بخش امنیتی RiceGuard می‌شوند.
  2. رابط‌های هدایت داده به خروجی: فضاهای نام شبکه (Namespaces) متصدی انتقال ترافیک کاربران با مقدار net.ipv4.ip_early_demux = 0 فعالیت می‌کنند. بدین ترتیب موتورهای هدایت شبکه مستقیماً به کاوش درخت FIB پرداخته و درگیر جستجوهای بیهوده نمی‌شوند.
  3. حفاظت از سازوکارهای کنترلی و سامانه DNS: پورت‌های مدیریتی TCP و کارسازهای اختصاصی DNS در قلمروهای مجزا با tcp_early_demux = 1 پیکربندی شده‌اند تا ضمن تسریع پاسخ‌دهی، انسداد امنیتی از نشت نشانی DNS ممانعت نماید.