القناة الجانبية الخفية: كيف تكشف جودة الخدمة (QoS) خصوصية المستخدم
عندما تنشئ التطبيقات حزم بروتوكول الإنترنت (IP)، يصنف نظام التشغيل البيانات باستخدام حقل نقطة رمز الخدمات المتمايزة (DSCP - Differentiated Services Code Point)، وهو حقل مكوّن من 6 بتات ضمن بايت نوع الخدمة (ToS) في بروتوكول IPv4 أو فئة المرور في بروتوكول IPv6 المحددة في معيار RFC 2474. وتعيّن تطبيقات الاتصال الصوتي عبر الإنترنت (VoIP) فئة التمرير السريع (DSCP EF، القيمة الثنائية 101110، القيمة العشرية 46)، بينما تحدد اجتماعات الفيديو المرئية فئات التمرير المضمون (مثل AF41 بالقيمة 34)، وتستخدم الألعاب التفاعلية علامات الاستجابة الفورية.
وفي بيئة الاتصال الآمنة، يُفترض بتغليف البيانات داخل نفق مشفر (مثل WireGuard أو IPsec ESP أو OpenVPN) حجب طبيعة أنشطة المستخدم تماماً، بحيث تظهر الحزم المشفرة للمراقب الخارجي في صورة تدفق عشوائي متجانس.
إلا أن الكثير من إعدادات الأنفاق الشائعة تقع في خلل معماري مؤثر: حيث تقوم تلقائياً بنسخ بايت ToS/DSCP من ترويسة الحزمة الداخلية الأصلية إلى ترويسة IP الخارجية التابعة للتغليف.
وعندما يقوم مزود خدمة الإنترنت (ISP) أو أي متصنت على الشبكة بفحص ترويسات الحزم الخارجية لتدفق VPN المشفر، فلن يتمكن من فك تشفير المحتوى، ولكن نظراً لأن بتات DSCP الخارجية تعكس بدقة أولويات الحزم الأصلية، يحصل المراقب على تصنيف فوري لنوع النشاط:
- يستطيع مزود الخدمة رصد بداية المكالمات الصوتية المشفرة ومدتها بدقة بالغة.
- تميّز أجهزة التوجيه المتوسطة تنزيل الملفات في الخلفية (Best Effort
000000) عن جلسات سطر الأوامر عبر بروتوكول SSH (DSCP AF11). - تربط أنظمة الفحص العميق للحزم (DPI) بين أحجام الحزم والفواصل الزمنية وعلامات DSCP لبناء تصنيف دقيق للتطبيقات دون الحاجة لفك التشفير.
النفق المعرض للتسريب (نموذج Uniform):
[ الحزمة الداخلية: صوت VoIP (DSCP 46 / EF) ] ---> [ التغليف والتشفير ] ---> [ ترويسة IP الخارجية (DSCP 46 / EF) ]
|
v
مزود الخدمة يرصد المكالمة الصوتية!
النفق المحمي (نموذج Pipe وفق RFC 2983):
[ الحزمة الداخلية: صوت VoIP (DSCP 46 / EF) ] ---> [ التغليف والتشفير ] ---> [ ترويسة IP الخارجية (DSCP 0 / Best Effort) ]
|
v
مزود الخدمة يرى تدفقاً متجانساً فقط
نماذج أنفاق DiffServ وفقاً لمعيار RFC 2983: Uniform وPipe
لتنظيم سلوك الخدمات المتمايزة عبر طبقات التغليف المتعددة، أصدر فريق هندسة الإنترنت وثيقة RFC 2983 ("Differentiated Services and Tunnels"). وتحدد الوثيقة ثلاثة نماذج معمارية:
1. النموذج الموحد (Uniform Model)
في النموذج الموحد، تتعامل الشبكة مع النفق كجزء متصل ضمن نطاق توجيه واحد:
- تنسخ الترويسة الخارجية قيمة DSCP مباشرة من الترويسة الداخلية عند دخول النفق.
- تتولى أجهزة التوجيه الوسيطة إدارة الطوابير وجدولة الحزم بناءً على هذه الأولوية المنسوخة.
- عند مخرج النفق، تُكتب أي تعديلات أجرتها الشبكات الوسيطة على حقل DSCP في الترويسة الداخلية الأصلية قبل تسليمها.
ورغم أن النموذج الموحد يحافظ على استمرارية سياسات جودة الخدمة بين شبكات موثوقة، فإنه يعرض الخصوصية للخطر في الشبكات العامة بكشفه لسلوك التطبيقات.
2. نموذج الأنبوب (Pipe Model)
في نموذج الأنبوب، يُعامل النفق كدائرة نقل مستقلة تخضع لسياسة جودة خدمة منفصلة تماماً:
- في عقدة الدخول، تُعين قيمة DSCP للترويسة الخارجية وفق سياسة مشغل النفق وبصرف النظر عن أولوية الحزمة الداخلية.
- يُثبت حقل DSCP الخارجي عادة عند القيمة الافتراضية Best Effort (
0x00) أو فئة نقل موحدة. - تقتصر تعديلات أجهزة التوجيه الوسيطة على جدولة الحزم الخارجية فقط.
- عند فك التغليف في المخرج، تُهمل الترويسة الخارجية بالكامل، وتستعيد الحزمة الداخلية وسم DSCP الأصلي بلا تغيير.
يحقق نموذج الأنبوب عزلاً صارماً للبيانات الوصفية: لا يرى المراقب الخارجي سوى فئة بيانات موحدة وثابتة.
3. نموذج الأنبوب القصير (Short-Pipe Model)
يعمل نموذج الأنبوب القصير بنفس طريقة نموذج الأنبوب عبر شبكة النقل الوسيطة. ويكمن الاختلاف عند عقدة الخروج: تعتمد واجهة فك التغليف على فئة النقل الخارجية لجدولة طوابيرها المحلية قبل تمرير الحزمة المستعادة إلى وجهتها النهائية.
مخاطر النموذج الموحد في خدمات VPN التجارية
تعمل بوابات VPN التجارية وأنظمة الوصول عن بعد للشركات عبر شبكات عامة غير آمنة. ويؤدي تطبيق النموذج الموحد في هذه البيئات إلى مخاطر تشغيلية واضحة:
| وجه التهديد | أثر النموذج الموحد | حماية نموذج Pipe الصارم |
|---|---|---|
| بناء البصمة الرقمية | مرتفع: يتعرف مزود الخدمة على الصوت والفيديو | معدوم: يظهر التدفق الخارجي بقيمة DSCP موحدة |
| التحكم الانتقائي بالسرعة | خفض سرعة فئات الفيديو المكتشفة (AF4x) | معاملة الحزم بالتساوي كحركة UDP عادية |
| تسريب القنوات الجانبية | تمييز ضغطات لوحة المفاتيح عبر وسوم التفاعل | حجب الفروق الزمنية عبر ترويسة خارجية ثابتة |
| التلاعب بالأولويات | عبث الموجهات الخارجية بالأولويات الداخلية | التخلص من التعديلات الخارجية عند فك التغليف |
عندما تتمكن الشبكات الوسيطة من قراءة حقول DSCP الخارجية، تتاح لها فرصة فرض قيود انتقائية على السرعة دون الحاجة إلى اختراق طبقات التشفير.
الفصل بين إشعارات الازدحام (ECN) وتنقية حقول DSCP
من الأخطاء التقنية الشائعة عند محاولة منع تسريب وسوم DSCP القيام بتصفير كامل بايت ToS. إذ ينقسم هذا البايت المكون من 8 بتات إلى قسمين منفصلين وظيفياً:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | ECN |
+---+---+---+---+---+---+---+---+
رمز أولوية الخدمة إشعار الازدحام
(البتات 0 إلى 5) (البتان 6 و 7)
- DSCP (البتات 0-5): يحدد مستوى أولوية الحزمة، وهو الجزء الذي يجب حجبه (بضبطه على
000000) في الترويسة الخارجية لمنع تسريب المعلومات. - ECN (البتان 6-7): يتحكمان في الإشعار الصريح بالازدحام وفق معياري 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 (البتات 0-5) مع الحفاظ الدقيق على إشارات ECN (البتان 6-7).
التطبيق البرمجي في نواة لينكس: XFRM وWireGuard وNetfilter
1. سلوك نظام 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
2. آلية العمل في وحدة WireGuard
في كود المصدر الخاص ببروتوكول WireGuard لنواة لينكس (drivers/net/wireguard/)، يتم التعامل مع ترويسة UDP الخارجية ضمن ملف send.c:
/* مقتطف من آلية ضبط الترويسة الخارجية في WireGuard */
static void wg_send_packet(struct wg_device *wg, struct sk_buff *skb)
{
...
/* يستخرج WireGuard إشارات ECN مع تصفير DSCP الخارجي */
u8 ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
...
}
يطبق WireGuard في النواة نمطاً آمناً من نموذج Pipe افتراضياً، حيث تُرسل حزم UDP الخارجية بقيمة DSCP صفرية مع الحفاظ على بتات ECN. ومع ذلك، قد تتجاهل بعض تطبيقات مساحة المستخدم على أنظمة التشغيل الأخرى هذا الإجراء بسبب وراثة إعدادات المقابس الافتراضية.
تنقية الحزم الخارجة باستخدام eBPF وNftables
لضمان سلامة البيانات الوصفية عبر كافة أنواع بروتوكولات الأنفاق، يمكن للمهندسين استخدام آليات التصفية عند مخرج النظام.
1. التنقية عبر 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
}
}
2. التنقية البرمجية عبر 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;
/* التحقق من أن الحزمة موجهة لمنفذ النفق */
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";
التزام بروتوكول RiceGuard في VPNRice بنموذج الأنبوب الصارم
تعتمد شبكة VPNRice على معايير صارمة لحماية سرية البيانات الوصفية. ومن خلال بروتوكول RiceGuard، تطبق الأجهزة الطرفية والخوادم نموذج الأنبوب وفق معيار RFC 2983:
[ حركة بيانات تطبيقات المستخدم ]
- مكالمات الفيديو: DSCP AF41 (0x22)
- ألعاب الشبكة: DSCP CS2 (0x10)
- تصفح المواقع: DSCP CS0 (0x00)
|
v
[ محرك تغليف RiceGuard للعميل ]
1. تسجيل حالتي DSCP وECN في ذاكرة الجلسة المشفرة.
2. تشفير البيانات بواسطة خوارزمية ChaCha20-Poly1305.
3. بناء الترويسة الخارجية مع فرض قيمة DSCP ثابتة عند CS0 (0x00).
4. تطبيق قواعد RFC 6040 على بتات ECN الخارجية.
|
v
[ شبكة الإنترنت العامة / مزود الخدمة ]
- المظهر الخارجي: تدفق موحد تماماً لحزم UDP دون أي علامات تمييز.
- استحالة تصنيف نوعية الاتصالات أو معرفة أوقات المكالمات.
|
v
[ بوابة فك التغليف في خوادم RiceGuard ]
1. التحقق من التوقيع وفك تشفير البيانات بأمان.
2. قراءة إشعارات الازدحام ECN ودمجها مع الحزمة الداخلية.
3. استعادة علامات DSCP الأصلية لجدولتها في شبكة الوجهة.
- نمط خارجي متجانس: تحمل جميع الحزم المتبادلة بين أجهزة المستخدمين وخوادم VPNRice فئة المرور الموحدة
CS0، مما يمنع جهات الرصد من فصل البيانات الحساسة عن حركة المرور العادية. - تكامل كامل مع إشعارات الازدحام: بفضل الامتثال لمعيار RFC 6040، يحافظ RiceGuard على إشارات التنبيه المبكر للازدحام لمساعدة خوارزميات إدارة الطوابير في تجنب ضياع البيانات.
- انضباط تنفيذي داخل النواة: تمنع آليات التحقق المباشرة في النواة أي برامج خارجية من تعديل خصائص الحزم، موفرة حماية متسقة عبر مختلف الشبكات.
تسهم معالجة تسريب بيانات جودة الخدمة وفق RFC 2983 في منح مستخدمي VPNRice حماية موثوقة ضد أساليب المراقبة الإحصائية المعقدة.



