کانال جانبی پنهان: چگونه کیفیت خدمات (QoS) حریم خصوصی را به خطر می‌اندازد

هنگامی که برنامه‌های کاربردی بسته‌های داده IP را ارسال می‌کنند، سیستم‌عامل ترافیک را با استفاده از فیلد نقطه کد خدمات متمایز (DSCP - Differentiated Services Code Point) طبقه‌بندی می‌نماید. این فیلد ۶ بیتی درون بایت نوع سرویس (ToS) در IPv4 یا کلاس ترافیک در IPv6 مطابق استاندارد RFC 2474 قرار دارد. برنامه‌های مکالمه صوتی اینترنتی (VoIP) کلاس هدایت سریع (DSCP EF با مقدار ۴۶) را اعمال می‌کنند، سامانه‌های تماس تصویری کلاس هدایت مطمئن (مانند AF41 با مقدار ۳۴) را مشخص می‌سازند و بازی‌های آنلاین نیازمند اولویت‌های تأخیر اندک هستند.

در یک معماری امنیتی اصولی، کپسوله‌سازی داده‌ها درون یک تونل رمزنگاری‌شده (نظیر WireGuard، IPsec ESP یا OpenVPN) برای مخفی کردن جزئیات ارتباطات کاربر طراحی شده است. از دید ناظر بیرونی، ترافیک رمزشده باید کاملاً یکدست و مانند داده‌های تصادفی به نظر برسد.

با این وجود، بسیاری از پیکربندی‌های متداول دچار یک نقص ساختاری هستند: پشته شبکه بایت ToS/DSCP بسته اصلی داخلی را مستقیماً و بدون تغییر درون سرآیند بیرونی بسته IP کپی می‌کند.

اگر یک ارائه‌دهنده خدمات اینترنت (ISP) یا ناظر شبکه محلی سرآیندهای بیرونی جریان داده‌های رمزشده را بررسی کند، اگرچه قادر به رمزگشایی محتوا نیست، اما به دلیل انعکاس مستقیم بیت‌های DSCP در لایه بیرونی، می‌تواند به آسانی ماهیت داده‌ها را طبقه‌بندی کند:

  • ارائه‌دهنده اینترنت زمان دقیق شروع، مدت و فواصل مکالمات صوتی رمزشده را تشخیص می‌دهد.
  • مسیریاب‌های میانی ترافیک بارگیری فایل در پس‌زمینه (Best Effort 000000) را از نشست‌های تعاملی SSH (مقدار DSCP AF11) متمایز می‌سازند.
  • سامانه‌های تحلیل عمیق بسته (DPI) با مقایسه اندازه بسته‌ها، فواصل زمانی و برچسب‌های DSCP، الگوی فعالیت برنامه‌های کاربر را به دقت تحلیل می‌نمایند.
تونل آسیب‌پذیر (مدل Uniform):
[ بسته داخلی: صوت VoIP (DSCP 46 / EF) ] ---> [ کپسوله‌سازی ] ---> [ سرآیند بیرونی (DSCP 46 / EF) ]
                                                                               |
                                                                               v
                                                            شناسایی مکالمه صوتی توسط ISP!

تونل ایمن (مدل Pipe بر اساس RFC 2983):
[ بسته داخلی: صوت VoIP (DSCP 46 / EF) ] ---> [ کپسوله‌سازی ] ---> [ سرآیند بیرونی (DSCP 0 / Best Effort) ]
                                                                               |
                                                                               v
                                                            مشاهده جریانی کاملاً یکنواخت

مدل‌های تونل DiffServ در سند RFC 2983: بررسی Uniform و Pipe

برای تدوین تعامل خدمات متمایز با لایه‌های کپسوله‌سازی، گروه مهندسی اینترنت سند RFC 2983 ("Differentiated Services and Tunnels") را منتشر کرده است که سه الگوی اصلی را معین می‌کند:

۱. مدل یکنواخت (Uniform Model)

در مدل یکنواخت، شبکه تونل را امتداد پیوسته یک دامنه مسیریابی تلقی می‌کند:

  • در ورودی تونل، سرآیند بیرونی مقدار DSCP را مستقیماً از بسته داخلی کپی می‌کند.
  • مسیریاب‌های میانی اینترنت بر اساس این اولویت بسته‌ها را در صف‌ها زمان‌بندی می‌کنند.
  • هنگام خروج از تونل، هرگونه تغییر ایجادشده در DSCP توسط شبکه‌های میانی مجدداً به بسته اصلی داخلی اعمال می‌شود.

اگرچه مدل Uniform پیوستگی اولویت‌ها را در شبکه‌های سازمانی حفظ می‌کند، اما در شبکه‌های عمومی با آشکارسازی ویژگی‌های رفتاری به محرمانگی لطمه می‌زند.

۲. مدل لوله‌ای (Pipe Model)

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

  • در گره ورودی، سرآیند بیرونی مقداری متناسب با سیاست فراهم‌کننده تونل دریافت می‌کند و از برچسب بسته داخلی صرف‌نظر می‌گردد.
  • فیلد DSCP بیرونی معمولاً روی مقدار پایه Best Effort (0x00) یا سطحی یکسان تنظیم می‌شود.
  • تغییرات گره‌های میانی تنها بر انتقال بسته خارجی اثر می‌گذارد.
  • در گره خروجی، سرآیند بیرونی حذف شده و بسته اصلی با مقدار اولیه DSCP به مقصد تحویل داده می‌شود.

مدل Pipe نوعی ایزوله‌سازی کامل متاداده ایجاد می‌کند؛ زیرا ناظر بیرونی فقط جریانی با خصوصیات پایدار مشاهده می‌کند.

۳. مدل لوله‌ای کوتاه (Short-Pipe Model)

مدل Short-Pipe در تمام طول مسیر میانی شبیه مدل Pipe عمل می‌کند. تفاوت آن در گره خروجی است: رابط گره قبل از فرستادن بسته احیاشده به مقصد، زمان‌بندی صف‌های محلی را بر مبنای کلاس بیرونی انجام می‌دهد.

پیامدهای منفی مدل Uniform در گیت‌وی‌های تجاری VPN

سرویس‌های VPN و درگاه‌های سازمانی همواره در بستر شبکه‌های عمومی ناامن کار می‌کنند. استفاده از مدل Uniform در این محیط‌ها چالش‌هایی در بر دارد:

عامل ریسک پیامد در مدل Uniform محافظت در مدل Strict Pipe
تحلیل رفتار ترافیک بالا: ISP صوت، تصویر و داده‌ها را تفکیک می‌کند صفر: جریان بیرونی برچسب یکنواخت Best Effort دارد
محدودسازی انتخابی کاهش عمدی پهنای باند کلاس‌های ویدئویی (AF4x) رفتار یکسان با بسته‌ها به عنوان ترافیک عادی UDP
نشت کانال‌های جانبی تشخیص تایپ کلیدها با برچسب‌های تعاملی مخفی‌سازی تغییرات زمانی با سرآیند ثابت
دستکاری بیرونی تغییر اولویت‌های داخلی توسط مسیریاب‌های عبوری حذف دگرگونی‌های خارجی هنگام خروج از تونل

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

تفکیک سیگنال‌های ECN (RFC 6040) از پاکسازی DSCP

یکی از اشتباهات متداول هنگام مقابله با نشت متادیتای DSCP، پاک کردن کامل کل بایت ToS است. این فیلد ۸ بیتی در واقع از دو بخش مجزا تشکیل شده است:

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|          DSCP         |  ECN  |
+---+---+---+---+---+---+---+---+
     کد اولویت سرویس         اعلام تراکم
       (بیت ۰ تا ۵)          (بیت ۶ و ۷)

۱. DSCP (بیت‌های ۰ تا ۵): اولویت بسته را تعیین می‌کند و باید در سرآیند بیرونی با صفر (000000) پوشانده شود تا مانع فاش شدن ماهیت داده گردد. ۲. ECN (بیت‌های ۶ و ۷): اعلان صریح تراکم را مطابق استانداردهای RFC 3168 و RFC 6040 مدیریت می‌کند. این بیت‌ها به مسیریاب‌ها امکان می‌دهند بدون دورانداختن بسته‌ها، گیرنده‌ها را از پر شدن صف‌ها باخبر سازند (00 = پشتیبانی نمی‌شود، 01 = ECT(1)، 10 = ECT(0)، 11 = بروز تراکم).

اگر مدیر شبکه کل بایت را صفر کند (ToS = 0x00)، قابلیت ECN از بین می‌رود. الگوریتم‌های نوین مدیریت صف فعال (مانند CoDel، FQ-CoDel و CAKE) به این نشانه‌ها متکی هستند. در نبود ECN، مسیریاب‌ها ناچار به حذف بسته‌ها می‌شوند که به نوسان پینگ و افت کیفیت می‌انجامد.

سند RFC 6040 قواعد مشخصی برای هدایت ECN در تونل‌ها تعیین نموده است:

  • هنگام کپسوله‌سازی، بیت‌های ECN بیرونی باید وضعیت بسته داخلی را منعکس نمایند.
  • هنگام خروج، چنانچه سرآیند بیرونی هشدار تراکم (11) دریافت کرده باشد، این هشدار باید به بسته داخلی منتقل گردد.

از این رو، سامانه‌های پیشرفته تنها بیت‌های DSCP (۰ تا ۵) را پاکسازی می‌کنند و بیت‌های ECN (۶ و ۷) را حفظ می‌نمایند.

پیاده‌سازی در هسته لینوکس: XFRM، WireGuard و Netfilter Mangle

۱. سازوکار زیرسیستم Linux IP-XFRM (IPsec)

در پیکربندی‌های IPsec در لینوکس با ابزار ip xfrm، ساختار هسته (struct xfrm_state) در صورت عدم تعیین، مقدار ToS داخلی را در سرآیند بیرونی کپی می‌کند. با iproute2 می‌توان این پارامتر را ثابت کرد:

# بررسی وضعیت‌های فعال XFRM
ip xfrm state show

# تعیین فیلد ToS بیرونی برای اجرای مدل Pipe مطابق RFC 2983:
ip xfrm state update src 203.0.113.10 dst 198.51.100.20 \
    proto esp spi 0x1000 reqid 1 mode tunnel \
    tos 0x00

۲. شیوه اجرا در درایور WireGuard

در ماژول رسمی WireGuard برای هسته لینوکس (drivers/net/wireguard/)، آماده‌سازی سرآیند بیرونی در بخش send.c انجام می‌گیرد:

/* بخشی از منطق مقداردهی سرآیند در WireGuard */
static void wg_send_packet(struct wg_device *wg, struct sk_buff *skb)
{
    ...
    /* استخراج ECN توسط WireGuard همزمان با صفر کردن DSCP */
    u8 ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
    ...
}

پروتکل WireGuard در هسته لینوکس به شکل پیش‌فرض رویکرد محافظت‌شده مدل Pipe را به کار می‌برد و بسته بیرونی را با DSCP صفر و بیت‌های صحیح ECN ارسال می‌کند. البته برخی برنامه‌های کاربری در سایر پلتفرم‌ها به دلیل ارث‌بری متغیرهای سوکت میزبان ممکن است این رویه را نقض کنند.

یکنواخت‌سازی ترافیک خروجی به کمک eBPF و Nftables

برای اطمینان از ایزوله‌سازی متاداده روی انواع پروتکل‌ها، فیلترهای سطح هسته قابل پیاده‌سازی هستند.

۱. پالایش از طریق Nftables

قاعده nftables زیر بسته‌های UDP تونل (پورت 51820) را بررسی کرده و ۶ بیت بالای ToS را صفر می‌کند، در حالی که ۲ بیت پایین ECN محفوظ می‌ماند:

table inet vpn_sanitizer {
    chain egress_filter {
        type filter hook postrouting priority mangle; policy accept;

        # تنظیم DSCP خارجی روی cs0 و حفظ ECN
        udp dport 51820 ip dscp set cs0
        udp dport 51820 ip6 dscp set cs0
    }
}

۲. اصلاح با بهره‌گیری از eBPF (tc-bpf)

در گیت‌وی‌های با حجم ترافیک بالا، برنامه eBPF متصل به نقطه خروجی clsact می‌تواند سرآیندها را مستقیماً در بافر حلقه‌ای هسته اصلاح نماید:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

SEC("classifier/egress_dscp")
int sanitize_outer_dscp(struct __sk_buff *skb)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return BPF_OK;

    if (eth->h_proto == __constant_htons(ETH_P_IP)) {
        struct iphdr *iph = (void *)(eth + 1);
        if ((void *)(iph + 1) > data_end)
            return BPF_OK;

        /* بررسی تعلق بسته UDP به پورت اختصاصی تونل */
        if (iph->protocol == IPPROTO_UDP) {
            /* حفظ بیت‌های ECN (ماسک 0x03) و صفرسازی بیت‌های DSCP */
            __u8 old_tos = iph->tos;
            __u8 new_tos = old_tos & 0x03;

            if (old_tos != new_tos) {
                bpf_l3_csum_replace(skb, offsetof(struct iphdr, check),
                                    old_tos, new_tos, sizeof(new_tos));
                iph->tos = new_tos;
            }
        }
    }
    return BPF_OK;
}

char _license[] SEC("license") = "GPL";

اجرای مدل Strict Pipe در پروتکل RiceGuard متعلق به VPNRice

سرویس VPNRice مسیر پردازش داده‌ها را با تأکید بر حفظ حریم خصوصی متاداده طراحی کرده است. در قالب پروتکل اختصاصی RiceGuard، ایستگاه‌های کاربری و سرورها مدل Pipe را طبق الزامات RFC 2983 پیاده می‌سازند:

[ ترافیک برنامه‌های کاربر ]
  - تماس تصویری:   DSCP AF41 (0x22)
  - ارتباطات بازی:   DSCP CS2  (0x10)
  - مرور وب‌سایت‌ها: DSCP CS0  (0x00)
             |
             v
[ موتور کپسوله‌سازی RiceGuard در کلاینت ]
  ۱. ثبت وضعیت DSCP و ECN بسته داخلی در حافظه امن نشست.
  ۲. رمزنگاری بار داده با الگوریتم مدرن ChaCha20-Poly1305.
  ۳. ساخت سرآیند IP/UDP بیرونی با مقدار اجباری CS0 (0x00).
  ۴. محاسبه مقادیر ECN بیرونی با تکیه بر دستورالعمل‌های RFC 6040.
             |
             v
[ شبکه اینترنت عمومی / شرکت ارائه‌دهنده ارتباطات ]
  - نمای ظاهری: جریانی کاملاً یکنواخت از بسته‌های UDP بدون علائم متمایز.
  - عدم امکان تفکیک مکالمات، ویدئوها یا داده‌های متنی.
             |
             v
[ گیت‌وی خروجی RiceGuard ]
  ۱. راستی‌آزمایی تگ اصالت و رمزگشایی ایمن بسته.
  ۲. استخراج هشدارهای تراکم ECN و ترکیب آن با بسته داخلی.
  ۳. بازگردانی برچسب‌های DSCP اولیه برای زمان‌بندی در شبکه مقصد.

۱. نمای بیرونی همگن: تمامی بسته‌های مبادله‌شده بین دستگاه کاربر و سرورهای VPNRice با کلاس واحد CS0 منتقل می‌شوند و امکان تفکیک ارتباطات مهم از ترافیک پس‌زمینه را سلب می‌کنند. ۲. انتقال بدون افت ECN: به کمک پیروی دقیق از RFC 6040، پروتکل RiceGuard ارتباطات کم‌تأخیر را حفظ کرده و به الگوریتم‌های صف اجازه می‌دهد بدون حذف بسته‌ها، مانع از افزایش تأخیر شوند. ۳. پایداری ساختاری هسته: کنترل مستقیم در لایه شبکه از ایجاد هرگونه نشت ناخواسته بر اثر تغییرات محیط کاربری ممانعت به عمل می‌آورد.

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