تصنيف هذا الدليل: VPN

منذ ما يزيد على عام، تتعطل إمكانية الوصول إلى مئات المواقع والخدمات العاملة خلف Cloudflare كلما انطلقت مباريات LaLiga لكرة القدم. وأيسر الطرق المجرّبة للاستفادة من تجاوز حجب المواقع باستخدام VPN، سواء عبر خدمة مدفوعة من ضمن الخدمات المتاحة أم خدمة مجانية مثل WARP التي تقدمها Cloudflare نفسها (وقد حُجبت هذه الأخيرة مرة واحدة فقط حتى اليوم). وإذا ثبّتّ عميل VPN على موجّهك، فبوسعك توجيه تدفق أجهزة معينة داخل شبكتك عبر النفق. غير أننا في هذا الدليل سنتبع مساراً أدق: إمرار التدفق المتجه إلى Cloudflare وحده عبر VPN، حتى لا نضطر إلى تمرير كامل حركة الشبكة داخل النفق ونحمّل بقية الأجهزة أثر ذلك في زمن الاستجابة وسرعة الاتصال.
ننوّه منذ البداية إلى أن هذا الشرح موجّه لفئة متقدمة من المستخدمين، غير أن الالتزام بجميع الخطوات سيجعل الضبط ممكناً ومنظماً تماماً على موجّه مزوّد بـنظام التشغيل pfSense. تحتاج العملية إلى معرفة مسبقة في إدارة واجهات الشبكة، وقواعد الجدار الناري (Firewall)، والمفاهيم الأساسية لـ VPN في pfSense. ونوصي بتجربة جميع الخواتم على بيئة اختبارية قبل إسقاطها على شبكة إنتاجية تعتمد عليها فعلياً.
وتلعب التوافقية دوراً محورياً في هذه العملية، إذ ليست كل الفيرمويرات أو أنظمة الموجّهات قابلة للاستخدام، لأن الإعداد يعتمد على خيارات متقدمة لا يوفرها الجميع. فالموجّهات المشهورة والمتكاملة مثل ASUS وFRITZ!Box وTP-Link وNETGEAR وغيرها لا تنفع للمهمة، بينما تنحصر التوافقية في الموجّهات العاملة بأنظمة مثل pfSense وOPNsense أو أجهزة Mikrotik. ويلخّص الجدول الآتي الفرق بين الفئتين:
| الفئة | الحالة | أمثلة |
|---|---|---|
| أنظمة مخصصة للموجّهات | متوافقة | pfSense، OPNsense، Mikrotik |
| فيرمويرات المصنع | غير متوافقة | ASUS، FRITZ!Box، TP-Link، NETGEAR |
ولتقريب الفكرة، تخيّل طريقاً سريعاً عاماً انطبقت إحدى بواباته منعاً من العبور: الحل الذكي ليس نقل شارع كامل إلى مسار بديل، بل تمرير الرحلات المتجهة إلى تلك البوابة تحديداً عبر ممر جانبي مخصص. وبالمنطق ذاته سنتعامل مع حركة Cloudflare داخل شبكتك المنزلية.
جدول المحتويات
- ما فائدة تمرير التدفق المتجه إلى Cloudflare عبر النفق؟
- المتطلبات
- إعداد pfSense خطوة بخطوة
- النتيجة النهائية بعد ضبط التوجيه
- أشهر الأخطاء أثناء الإعداد وكيفية حلها
- الأسئلة الشائعة
- نظام التشغيل المتوافق مع الراوتر
- خدمة VPN بتقنية WireGuard
- ضبط عميل VPN الخاص بـ WireGuard
- إنشاء الواجهة الافتراضية وضبط البوابة (Gateway)
- إنشاء الأسماء البديلة (Aliases) لعناوين المصدر وشبكات الوجهة
- إنشاء قاعدة في جدار الحماية
- إنشاء قاعدة في NAT Outbound
- خطوات بسيطة للتأكد من نجاح الإعداد
- أخطاء متعلقة بقواعد الجدار الناري
- أخطاء متعلقة بالبوابة وإعدادات WireGuard
ما فائدة تمرير التدفق المتجه إلى Cloudflare عبر النفق؟
عندما نثبّت VPN على الموجّه ونوجّه التدفق عبر النفق، يتعين علينا اختيار جهاز واحد أو عدة أجهزة أو كافة الأجهزة المتصلة بالشبكة، لتخرج إلى الإنترنت عبر خادم VPN المضبوط في العميل. وبهذا يمر كامل تدفق هذه الأجهزة عبر VPN، وهو نهج غير فعّال إذا كان هدفك محصوراً في تجاوز حجب Cloudflare والوصول إلى مواقعك المفضلة التي تعاني حجبها.
تخيّل الأمر كأنك تجبر كل سكان عمارة على الخروج من باب الخدمات لأجل أن يغلق الباب الرئيسي أمام بعضهم: سيخرج الجميع فعلاً، لكن على حساب الوقت وسهولة الحركة. والشبه بذلك إجبار كافة أجهزة الشبكة على المرور بالنفق من أجل مواقع محددة، فتصبح بقية الاتصالات أبطأ مما يجب دون داعٍ.
في هذا الشرح سنمرر حصراً التدفق المتجه إلى Cloudflare، بينما يسير بقية التدفق عبر اتصال الإنترنت «الاعتيادي». وتظهر فوائد هذه الاستراتيجية بوضوح:
- ستحصل على زمن استجابة أقل أثناء اللعب أو التصفح أو مشاهدة الفيديو عبر البث؛ فما دامت وجهة الحزمة خارج شبكة Cloudflare، سيعمل كل شيء بوضعه الطبيعي تماماً.
- ستحافظ على السرعة ذاتها التي اعتدت عليها؛ فإعداد أي عميل VPN يعني خسارة جزئية في المعدل، لأن عمليات تشفير التدفق وفك تشفيره تفرض عبئاً على الأداء، خصوصاً إذا كانت خطتك عبر الألياف البصرية بمعدل 1Gbps متناظر أو أعلى.
إضافة إلى ذلك، إذا كنت تستخدم خدمات تعتمد على تحديد الموقع الجغرافي مثل تطبيقات البنوك، فلن تواجه أي إشكال بسبب وجود VPN في بلد آخر؛ لأن هذا التدفق بعينه يخرج من الاتصال العادي، ما لم تكن تلك الخدمة تحمي نفسها عبر شبكة Cloudflare ضد الهجمات.
المتطلبات
هذا الدليل موجّه حصراً لمن يمتلك خبرة شبكية جيدة، إذ لا يمكن تطبيقه على راوترات المنازل العادية مهما بلغت شركاتها من تطوير في الفيرموير، مثل ASUS وFRITZ!Box وTP-Link وQNAP وغيرها. هذه الأجهزة قد تدعم VPN بشكل أساسي، لكنها تفتقر إلى الأدوات الأساسية التي نحتاجها هنا: الواجهات الافتراضية، ووسم الترافيك، والتوجيه الدقيق للحزم. بعبارة أخرى، ما سنقوم به يشبه تحويل الراوتر من نقطة مرور اعتيادية إلى شرطي مرور يقرر بدقة أي حزمة تسلك أي طريق.
نظام التشغيل المتوافق مع الراوتر
طبّقنا كل ما ستقرأه هنا على نظام pfSense CE 2.8.1، ونؤكد لك أن الخطوات تعمل أيضاً على الأنظمة التالية:
- pfSense Plus
- OPNsense
- Mikrotik، حيث تكون الفكرة نفسها لكن عبر أدوات نظام RouterOS.
يتوفر حالياً عدد كبير من أجهزة appliance التي يمكن تثبيت pfSense أو OPNsense عليها لتعمل بوصفها الراوتر الرئيسي في المنزل بخيارات متقدمة جداً. واعرف أن قوة العتاد تحدد مباشرة قدرتك على تمرير كميات أكبر من حركة البيانات عبر النفق أو كميات أقل. جهاز Slimbook Zero Intel N150 خيار ممتاز له هذا الغرض، إذ يتوفر بسعر يقارب 321.50 يورو، وإذا كان تفضيلك أنّ تثبت OPNsense فحل بديل موفّق هو Protectli.
أما إذا كنت تعتمد على راوترات من فئة الأعمال أو راوترات متقدمة، فيمكن أن تكون متوافقة مع الشرح بشرط توفر الخصائص التالية:
- عميل VPN يدعم OpenVPN أو WireGuard.
- إمكانية إنشاء واجهة افتراضية لنفق VPN.
- إمكانية إنشاء «أسماء مستعارة» (Aliases) لتسجيل جميع نطاقات عناوين IP التابعة لـ Cloudflare.
- خيارات لـ «وسم» الترافيك (Traffic Marking) لإجبار حركة البيانات المطابقة على المرور عبر بوابة الواجهة الافتراضية للنفق.
خاصية الوسم تلك هي قلب العملية كلها؛ فهي أشبه بوضع ملصق مميز على ظرف الرسائل، فأي حزمة تحمل الملصق يتعرف عليها النظام فيأمرها بسلوك النفق الافتراضي، أما بقية الحزم فتكمل طريقها بشكل طبيعي تماماً. بهذا الفصل الدقيق تضمن أن زياراتك للمواقع المستهدفة تمر عبر الشبكة الافتراضية دون أن تتأثر بقية أجهزة منزلك.
الحد الأدنى لمتطلبات العتاد والشبكة
| المكوّن | الحد الأدنى | الموصى به |
|---|---|---|
| المعالج | معالج 64 بت (x86-64/amd64) بسرعة 1 جيجاهرتز | Intel Core i5 أو أفضل من عدة أنوية |
| الذاكرة RAM | 1 جيجابايت | من 4 إلى 8 جيجابايت (خصوصاً مع VPN/WireGuard) |
| التخزين | 8 جيجابايت (SSD أو HDD) | 128 جيجابايت SSD لموثوقية أعلى |
| واجهات الشبكة | واجهتان كحد أدنى (WAN + LAN) | ثلاث واجهات فأكثر لمرونة أكبر (WAN، LAN، DMZ) |
| البطاقات الموصى بها | بطاقات Intel قدر الإمكان لأقصى توافق | |
| التثبيت | منفذ USB قابل للإقلاع أو وحدة DVD لملف ISO |
إذا توفرت لديك هذه الخصائص فستتمكن من تطبيق خطواتنا بلا عقبات، مع الإشارة إلى أن الشرح مُنجز هذا على pfSense تحديداً كما أوضحنا من البداية.
خدمة VPN بتقنية WireGuard
بعد استيفاء شرط نظام التشغيل، يأتي الشرط الثاني وهو الأهم: توفر خادم VPN يعمل ببروتوكول WireGuard أو OpenVPN، لأن تجاوز حجب المواقع باستخدام VPN يبدأ من هذا النفق تحديداً. أمامك عدة خيارات عملية وجدت جدارتها:
- الاشتراك في خدمة VPN مدفوعة مثل NordVPN أو Surfshark أو CyberGhost أو PrivadoVPN أو PureVPN وغيرها. تكفي تسجيل نفسك وشراء الاشتراك، ثم تنزّل ملف الإعدادات واستورده داخل الراوتر. يوفّر كل مزوّد شرحاً لطريقة الحصول على ذلك الملف دون المرور بتطبيقاته؛ اختر وضع «Router» فتظهر لك البيانات اللازمة مباشرة.
- استخدام خدمة WARP من Cloudflare، وهي مناسبة للتجارب السريعة، لكن ضع في حسبانك أن المشغلين قد يضعونها على قائمة الحجب، فتعامل معها بحذر.
- استئجار VPS اقتصادي (خادم افتراضي) من منصات مثل Kamatera أو OVH أو Ginernet، وتنصيب خادم WireGuard عليه بنفسك للحصول على تحكم كامل.
الاختيار بين هذه الحلول يشبه قرار الإقامة أثناء السفر: الخدمات التجارية فندق جاهز مقابل إيجار شهري، وWARP بيت أصدقاء مجاني لكنه غير مضمون، أما VPS فهو شقة تستأجرها وترتبها وتتحكم فيها بكل حرية. وقبل الانتقال إلى الإعدادات، إليك الجدول الذي يلخّص المقارنة بين الخيارات الثلاثة:
| خيار VPN | البروتوكول الموصى به | التكلفة التقريبية | الأنسب لمن |
|---|---|---|---|
| VPN تجاري (NordVPN، Surfshark وغيرها) | WireGuard | من 5 إلى 10 يورو شهرياً | المستخدمون الباحثون عن البساطة وخوادم موزعة في عدة دول |
| Cloudflare WARP | WireGuard | مجاناً | تجارب سريعة وحل بدون تكلفة، مع احتمال حجبه مستقبلاً |
| VPS خاص (Kamatera، OVH وغيرهما) | WireGuard | من 3 إلى 6 يورو شهرياً | المستخدمون المتقدمون الراغبون في تحكم كامل بأقصى خصوصية |
حين يصل ملف إعدادات عميل VPN بين يديك، تصبح الخطوة التالية واضحة تماماً: استيراده إلى النظام والبدء بتفعيل النفق داخل الشبكة المنزلية. هنا تبدأ مرحلة الإعداد الفعلي التي سنشرحها بالتفصيل في القسم المقبل.
إعداد pfSense خطوة بخطوة
اعتمدنا هنا تثبيتاً نظيفاً بالكامل لنظام pfSense، إذ ضبطنا واجهة WAN على نمط DHCP وبقيت شبكة LAN على عنوانها المعتاد 192.168.1.1. بعد انتهاء العملية ستبدو القائمة الرئيسية للنظام بهذا الشكل:
الخطوة الأولى هي تثبيت حزمة WireGuard داخل النظام لأنها لا تأتي مفعّلةً بطبيعتها. ننصح بشدة باعتماد هذا البروتوكول لمن يفكر في تجاوز حجب المواقع باستخدام VPN، فهو يجمع بين أعلى درجات الحماية وأفضل سرعة تحميل ورفع ممكنة، بينما تبقى بروتوكولات أخرى مثل OpenVPN أبطأ بشكل واضح. لذلك اختر WireGuard كلما توفرت لديك الفرصة.
بمجرد اكتمال التثبيت تصبح لدينا القدرة على ضبط عميل VPN انطلاقاً من بيانات خادم WireGuard الذي نمتلكه.
ضبط عميل VPN الخاص بـ WireGuard
من أجل استيراد ملف الإعدادات نتجه إلى القائمة «VPN (WireGuard)»، ثم نضغط «Add tunnel» لإضافة أول نفق VPN لنا:
الآن يأتي دور نسخ إعدادات عميل VPN، وإذا اتخذنا الملف التالي مرجعاً لعملنا:
[Interface]
PrivateKey = xxxxx
Address = 10.99.0.2/32
DNS = 1.1.1.1
[Peer]
PublicKey = xxxxxxxx
PresharedKey = xxxxxxxxxx
AllowedIPs = 0.0.0.0/0
Endpoint = xxxx:yyyyy
PersistentKeepalive = 25
علينا تعبئة الإعدادات التالية في القوائم المختلفة:
- Enable: نفعّل الخيار.
- Description: وصف قصير للنفق، وسيفيدك كثيراً إن أنشأت أنفاقاً إضافية لاحقاً.
- Listen Port: يمكن تركه كما هو، أو اختيار بورت آخر بحرية.
- Interface keys: ننسخ «PrivateKey» كما وردت في ملف الإعدادات، بينما تُحسب «Public key» بشكل تلقائي.
نضغط الآن على «Save»، ثم نضغط زر «Add peer» لإضافة النظير (Peer) إلى نفق WireGuard. ويجب تعبئة الإعدادات التالية:

- Enable: نفعه كالمعتاد.
- Tunnel: مرتبط بالنفق الذي أنشأناه للتو، وسيظهر وصفه تلقائياً.
- Dynamic Endpoint: نلغي تحديده حتى نتمكن من إدخال الـ Endpoint والبورت.
- Endpoint: نضع عنوان IP العام أو النطاق مع البورت، وهما متوفران في خانة «Endpoint» من ملف الإعدادات.
- Keep alive: نضع 25 ثانية.
- Public Key: كما وردت في خانة «PublicKey» داخل الملف.
- Pre-shared Key: اختياري؛ بعض مزودي VPN لا يقدمون مفتاحاً مشتركاً، ومكانها خانة «PresharedKey» في الملف، فإن لم يكن لديك اتركه فارغاً.
- Allowed IPs: نضع 0.0.0.0 وفي خانة القناع نضع الرقم 0.
نضغط «Save» وبذلك يكتمل نفق WireGuard. ولتفعيله نتجه إلى «Settings» ونضغط «Enable» ثم «Save» فتنطلق الواجهة فوراً. تخيّل ما نفعله كأننا حفرنا نفق طريق خاص تحت الطريق السريع؛ صار الجسر جاهزاً، وكل ما ينتظرنا هو توجيه السيارات إلى مدخله بدل أن تنسحق في الزحام الممتد فوق السطح.
من القائمة الرئيسية يمكننا مراجعة الإعدادات التي أدخلناها، ومن تبويب «Status» نتحقق من نجاح الاتصال أو فشله.
في هذه المرحلة صار نفق WireGuard جاهزاً بالكامل، والخطوة التالية هي توجيه حركة البيانات من خلاله.
إنشاء الواجهة الافتراضية وضبط البوابة (Gateway)
ندخل إلى «Interfaces / Interface Assignments»، ومن خانة «Available network ports» نختار المنفذ «tun_wg0» الذي أنشأناه قبل قليل ونضغط «Add». بعدها نضغط «Save» ثم «Apply Settings» التي ستظهر بخط أخضر. صار لدينا الآن واجهة افتراضية مرتبطة بـ VPN لكنها لا تزال بحاجة إلى الضبط، فاضغط على اسم هذه الواجهة الجديدة وسينقلك الأمر إلى قائمة «Interfaces / OPT1 (tun_wg0)».
في هذه القائمة نضبط العناصر الآتية:
- Enable: نفعّل الواجهة.
- Description: وصف قصير سيصبح اسم الواجهة، ولا تختر اسماً «طويلاً» حتى لا يظهر بشكل مشوه في القوائم الأخرى.
- IPv4 Configuration Type: اختر Static IPv4.
- IPv6 Configuration Type: اتركه none كما هو افتراضياً.
وفي قسم «Static IPv4 configuration» ندخل ما يلي:
- IPv4 Address: العنوان 10.99.0.2 مع القناع /32.
تُستمد هذه القيمة مباشرة من ملف إعدادات WireGuard؛ أي نضع ما هو نفسه الموجود في الملف، وفي حالتنا «Address = 10.99.0.2/32». نضغط «Save» ونطبق التغييرات، وبذلك تكتمل عملية ضبط الواجهة.
المطلوب الآن معاملة هذه الواجهة الافتراضية كـ «Gateway» أو بوابة خروج، ولكي نفعل ذلك نتوجه إلى «System / Routing / Gateways» ونضغط «Add» لإضافة بوابة جديدة، ونختار الواجهة «WG_TUNEL» التي أنشأناها سابقاً ثم نعدل الإعدادات كالآتي:
- Disabled: نبقيه بدون تحديد كي تُشغّل البوابة.
- Interface: نختار WG_TUNEL.
- Address Family: IPv4.
- Name: اسم وصفي للبوابة.
- Gateway: نضع 10.99.0.2 وهي العنوان الخاص بالـ VPN.
- Gateway monitoring: نتركه بدون تحديد.
- Gateway action: نتركه بدون تحديد.
- Monitor IP: عادةً أول عنوان من الشبكة الفرعية، أي 10.99.0.1 في حالتنا، لرصد الطرف الآخر من النفق عبر ping وعلمنا بالتالي إذا كان ساقطاً أم لا.
إعداد لا يحتمل الإهمال ينتظرك داخل قسم «Advanced»: فعّل خيار «Use non-local gateway though interface specific route». نضغط بعدها «Save» ثم «Apply changes» لتطبيق التغييرات. فكّر في هذه البوابة كأنها الباب الخارجي الوحيد لمبنى إداري كامل؛ إن أُسئ ضبطه فلن يجد أي زائر طريقه إلى الخارج مهما كانت بقية تجهيزات المبنى ممتازة.
بهذا تكون البوابة جاهزة تماماً، وستستقبل كل حركة البيانات التي نحددها في الخطوات القادمة.
إنشاء الأسماء البديلة (Aliases) لعناوين المصدر وشبكات الوجهة
تتيح لنا الـ Aliases تجميع عناوين IP أو شبكات كاملة تحت اسم وصفي واحد نستدعيه لاحقاً في جدار الحماية، والفائدة مزدوجة: تنظيم أنظف للقواعد، وعدم الحاجة إلى إنشاء عشرات القواعد المتشابهة التي تستنزف موارد الجدار الناري. العملية تشبه دفتر جهات الاتصال في هاتفك تماماً؛ فبدل حفظ الأرقام الطويلة في رأسك، تكفي بصمتك على الاسم. ندخل من القائمة «Firewall / Aliases»:
سننشئ أولاً بديلاً (Alias) يضم جميع عناوين IP المصدر، أي الأجهزة المحلية التي نريد «وسمها» ليمر عبر النفق، ويدخل حيز التنفيذ بشرط أن يكون الوجهة شبكات Cloudflare. أعطه اسماً واضحاً وأضف العناوين التي تحتاجها:
نحتاج بعد ذلك إلى بديل ثانٍ نضع فيه جميع عناوين Cloudflare، أو بعبارة أدق جميع شبكاتها الفرعية، بحيث يُمرَّر أي اتصال وجهته Cloudflare عبر النفق. ومن صفحة عناوين موقع Cloudflare نستعرض جميع الـ IP والشبكات الفرعية، بل ويمكن تنزيلها بصيغة نصية من الأسفل مباشرة لننسخها ونلصقها في pfSense على الفور.
من القائمة «Firewall / Aliases» نضغط زر «Import»، ثم نكتب اسم البديل ووصفه وننسخ جميع الشبكات الفرعية التي حصلنا عليها من Cloudflare. نضغط «Save» لإتمام عملية الاستيراد:
ولضمان ألا تتقادم إعداداتنا مع الوقت، يمكنك أيضاً اعتماد خيار «URL» داخل «Aliases» كي يحمّل النظام نطاقات العناوين ويجدّدها آلياً من المصدر الرسمي لـ Cloudflare. بيد أن استحالة وصول النظام إلى تلك الخدمة، إذا حُجبت، قد تمنع التنزيل. عموماً، هذه النطاقات نادراً ما تتغير؛ فسجلّ التعديلات يكشف أنه لم تُضف أو تُزال أي شبكة IPv4 منذ عام 2021. ضع في الخانة الرابط التالي لأنه تحديداً الذي يجلب القائمة بصيغة نصية:
https://www.cloudflare.com/ips-v4/#
في خانة «Update Frequency (Days)» ضع القيمة 1 ليتم التحديث يومياً.
ستظهر الآن القائمتان معاً في تبويب «Aliases»؛ اضغط «Apply changes» وصرت جاهزاً لإنشاء قاعدة جدار الحماية.
لم يبق إلا إنشاء القاعدة في الجدار الناري كي «نوسم» الحركة المطلوبة ونعيد توجيهها إلى النفق.
إنشاء قاعدة في جدار الحماية
نتوجه إلى قسم «Firewall / Rules» ونضغط على تبويب الشبكة الفرعية التي نطبق على القاعدة فيها، وعادةً ستكون LAN. هنا نضغط «Add Rule» (اختر الإضافة في الأسفل كي تُنشأ القاعدة في نهاية القائمة) وستظهر نافذة الإنشاء:
- Action: اختيار Pass.
- Disabled: بدون تحديد.
- Interface: اختيار LAN (أو أي واجهة تريد إضافة القاعدة إليها).
- Address Family: IPv4.
- Protocol: نتركه any (على مستوى IP).
- Source: نختار «Address or alias» ثم بديل عناوين المصدر الذي أعددناه قرب بداية الشرح.
- Destination: نختار «Address or alias» ثم بديل شبكات الوجهة، أي شبكات Cloudflare.
داخل قائمة «Advanced Options» نضغط زر الإظهار، ثم ننزل نزولاً حتى خيار «Gateway» ونختار بوابة «WireGuard» التي ضبطناها سابقاً. نضغط الآن «Save» ونطبق التغييرات.
انتبه جيداً إلى ترتيب القواعد داخل جدار الحماية: النظام وضع قاعدتنا الجديدة في آخر القائمة، وبقواعد pfSense الافتراضية لن تُطبَّق أبداً ولن تُوسم الحركة. من الضروري رفعها إلى الموضع الثاني كي تعمل بصورة صحيحة، أما بقية الحركة فستمر عبر القواعد الافتراضية الموجودة لدينا. تخيّل حارساً يقرأ قائمة تعليماته سطراً سطراً من أعلى إلى أسفل؛ التعليمة التي تصل في آخر السطور لا تغني إلا عن ما تبقى منها، ولا تلحق من وصل قبله.
من هذه اللحظة، كلما زرنا موقعاً مستضافاً ضمن شبكة Cloudflare سيمر اتصالنا تلقائياً عبر نفق VPN بدلاً من اتصالنا الحقيقي بالإنترنت، فلا نلتقط أي قيود من المشغلات وتسير الأمور بواقعية تامة.
إنشاء قاعدة في NAT Outbound
نبلغ الآن الخطوة الأخيرة: إنشاء قاعدة في «Firewall / NAT / Outbound». هنا نختار «Manual Outbound NAT» ونترك القواعد التي أنشأها النظام افتراضياً في أماكنها. ثم نضغط على خيار إضافة قاعدة جديدة في الأعلى كي تحوز القاعدة الجديدة أعلى أولوية ممكنة:
يكون إطار إعدادات القاعدة كالآتي:
- Interface: اختيار الواجهة التي أنشأناها سابقاً لتنفيذ نفق WireGuard.
- Address Family: اختيار IPv4.
- Protocol: اختيار Any.
- Source: اختيار Network or Alias، أي البيانات التي تضم عناوين المصدر.
- Destination: اختيار Network or Alias التي تحتوي عناوين الوجهة نحو Cloudflare أو المحظورة.
- Translation: اختيار Address ونضع عليه عنوان الـ VPN.
بهذا التصميم سيمر الاتجاه نحو Cloudflare عبر النفق بشكل صحيح في جميع الأحوال، وتظل بقية حركة الشبكة تعمل من دون أي تغير.
النتيجة النهائية بعد ضبط التوجيه
بعد تفعيل القاعدة، جرّب تنفيذ أمر traceroute وستلاحظ تغيّرًا واضحًا في مسار الحزم؛ إذ ستخرج عبر أنفاق الـ VPN مباشرة كلما كان الوجهة عنوان IP تابعًا لشبكة Cloudflare. وهنا تتجلى آلية تجاوز حجب المواقع باستخدام VPN عمليًا: إن اخترت إعداد WARP كعميل VPN (مع إمكانية أن تحجبه بعض الأنظمة)، فستجد نفسك داخل شبكة Cloudflare ذاتها، وستحصل على قفزة واحدة فقط وبأداء ممتاز وأقل زمن استجابة ممكن، تمامًا كمن يحادث جاره في الغرفة المجاورة بدل الاتصال الهاتفي من مدينة بعيدة.

أما إذا ضبطت خدمة VPN أخرى غير WARP، فستسلك الحزم طريقًا يضم قفزات أكثر بكل تأكيد، ويعتمد عددها على شكل التوجيه الداخلي انطلاقًا من خادم الـ VPN الذي تتصل به. المهم هنا ليس كثرة القفزات أو قلتها، بل أن الحركة تخرج فعلًا عبر النفق بدل المسار الافتراضي لمزود الخدمة.
خطوات بسيطة للتأكد من نجاح الإعداد
لا يكفي أن تبدو الإعدادات سليمة على الشاشة، بل يجب اختبار النتيجة ميدانيًا. والاختبار الحاسم يجمع بين حالتين متعاكستين:
- بترك القاعدة غير مفعّلة (أو مع تعطيلها مؤقتًا)، نفّذ أمر tracert نحو Cloudflare وسجّل عدد القفزات.
- بعد تفعيل القاعدة، نفّذ أمر tracert نحو Cloudflare وسجّل القفزات مرة أخرى.
قارن بعد ذلك بين نتيجتي traceroute: فإن كان المسار واحدًا في الحالتين، فالأرجح أنك وقعت في خطأ أثناء خطوات الإعداد. أما إذا اختلفت القفزات بين الحالتين، فهذا دليل واضح على أن الحركة تُوجَّه عبر الـ VPN، لأنك تكون قد تجاوزت آلية التوجيه الكاملة لدى مزود خدمة الإنترنت.
أشهر الأخطاء أثناء الإعداد وكيفية حلها
التوجيه القائم على السياسات (Policy-Based Routing) يمنحك إمكانية توجيه حركة مرور محددة نحو بوابات مختلفة، كنفق الـ VPN الذي أنشأته، استنادًا إلى معايير مثل عنوان IP المصدر (أجهزتك الشخصية) أو الوجهة أو شبكات بعينها (شبكة Cloudflare). وعند إنشاء نفق لـ Cloudflare عبر الـ VPN، يصبح ضبط قواعد الجدار الناري بدقة شرطًا أساسيًا لنجاح العملية كاملة.
أخطاء متعلقة بقواعد الجدار الناري
- ترتيب القواعد بشكل خاطئ: القواعد الأكثر خصوصية يجب أن تُوضَع قبل (فوق) القواعد العامة، وإلا فلن تُنفَّذ إطلاقًا. فالنظام يقيّم القواعد بالتسلسل من أعلى إلى أسفل، تمامًا كطابور أمام شباك التذاكر؛ وإن سمحت قاعدة عامة بمرور الحركة أولًا فلن يطّلع النظام على بقية القواعد، ولن يعمل التوجيه كما يجب. الحل: بعد إنشاء كل قاعدة، رتِّب القائمة بالكامل في الموضع الصحيح، ثم اضغط على «Save» ثم «Apply».
- عدم وضع إعداد لقاعدة NAT/outbound: في هذا السيناريو لا يلزم ضبط أي شيء داخل NAT، لأنك تعيد توجيه الحركة بالكامل وليس جزءًا محدودًا منها فقط.
- إدارة عدة عناوين IP أو وجهات دون استخدام الأسماء المستعارة (Aliases): إنشاء قاعدة منفصلة لكل عنوان مصدر أو وجهة يعني بناء عشرات القواعد، وهو ما يفسح المجال للأخطاء ويقلل الكفاءة كثيرًا. الحل الأمثل هو الاعتماد على Aliases في pfSense لتجميع العناوين أو الشبكات الفرعية أو النطاقات المستهدفة في قائمة واحدة، ثم بناء قاعدة مفردة تشير إلى هذا اللفظ الجامع. وهكذا يقصر الأمر على تحديث القائمة عند إضافة أو حذف عنوان IP، دون المساس بالقاعدة نفسها.
- الحركة لا تمر عبر الـ VPN: السبب الأكثر شيوعًا هو ترتيب قواعد الجدار الناري. تأكد من أن القاعدة التي أنشأتها لتوجيه حركة Cloudflare تقع في الموضع الثاني ضمن علامة التبويب «LAN»، أسفل قاعدة الحماية الافتراضية anti-lockout مباشرة، لأن القواعد تُعالَج من الأعلى إلى الأسفل.
أخطاء متعلقة بالبوابة وإعدادات WireGuard
- عدم تحديد خيار «Use non-local gateway» أو ضبط بوابة خاطئة: احرص على تحديد خانة «Use non-local gateway» كما هو مشروح في خطوات الإعداد. وإن اعتمدت واجهة VPN كبوابة بديلة، فتحقق من خيار «Advanced Options» ومن قائمة «Gateway» للتأكد من أن الضبط صحيح.
- ظهور واجهة البوابة بحالة «Offline»: توجه إلى «System / Routing / Gateways»، ثم عدِّل بوابة WireGuard الخاصة بك، ومن «Advanced Options» تأكد من تحديد خانة «Use non-local gateway». هذا خطأ واسع الانتشار عند استخدام الواجهات الافتراضية.
- انقطاع الاتصال بعد تفعيل القاعدة: راجع إعداد «Peer» في WireGuard وتأكد من أن حقل «Allowed IPs» مضبوط على 0.0.0.0/0 للسماح بمرور كل الحركة عبر النفق، فقاعدة الجدار الناري هي المسؤولة عن اختيار أيِّ حركة تدخل النفق بالضبط.
قد تصادفك بعض هذه المشكلات أثناء ضبط الإعدادات، لكن لا شيء منها يستدعي البدء من جديد؛ فكل حالة منها لها حل مباشر وسريع ما دمت تعرف موضع الخلل بدقة.
وإذا كنت تفضّل حلاً يعمل على مستوى الشبكة كاملة داخل منزلك بدلاً من الاكتفاء بجهاز واحد، فدليلنا خطوة بخطوة حول إعداد VPN على راوتر Keenetic والخروج إلى الإنترنت عبر النفق لتجاوز حجب مشغّل الخدمة يمنحك مساراً عملياً يغطي جميع أجهزتك دفعة واحدة.
بصفتنا منتسبين إلى Amazon وبرامج تسويق بالعمولة مماثلة أخرى، يحصل هذا الموقع على عوائد مقابل عمليات الشراء المرتبطة التي تستوفي شروط الأهلية المعمول بها.
الأسئلة الشائعة
ما فائدة تمرير التدفق المتجه إلى Cloudflare عبر النفق فقط بدلاً من إعادة توجيه كل حركة المرور؟ لأن معظم منصات البث المستهدفة بحجب LaLiga تخفي خوادمها خلف شبكة Cloudflare، فإن توجيه هذا التدفق تحديداً عبر النفق يفتح المحتوى دون تحميل بقية حركة الشبكة على الـ VPN. هذا الأسلوب يحافظ على سرعة التصفح والألعاب الإلكترونية عبر الاتصال المحلي، كما يقلل الضغط على خادم VPN واستهلاك البيانات.
ما المتطلبات الأساسية قبل البدء بإعداد pfSense لتخطي حجب LaLiga؟ تحتاج إلى جهاز يعمل بنظام pfSense، واشتراك فعّال في خدمة VPN مع خادم في دولة يُفتح فيها المحتوى، وبيانات اعتماد WireGuard أو OpenVPN من المزود. يُنصح أيضاً بجمع نطاقات المواقع المستهدفة مسبقاً لتحويلها إلى Alias داخل pfSense. تأكد من امتلاك صلاحيات كاملة على جهاز التوجيه لأن التعديل يتطلب الوصول إلى لوحة التحكم.
كيف أضبط التوجيه داخل pfSense خطوة بخطوة لتوجيه مواقع محددة عبر النفق؟ ابدأ بإنشاء واجهة النفق وتفعيلها ثم أضف بوابة (Gateway) خاصة بها. بعدها أنشئ Alias يجمع نطاقات المواقع المستهدفة، وأضف قاعدة على واجهة LAN تجعل أي تدفق متجه لهذا الاسم المستعار يمر عبر بوابة النفق. فعّل قاعدة NAT من نوع Outbound لترجمة العناوين عبر واجهة النفق ثم طبّق التغييرات واختبر النتيجة.
كيف أتأكد أن التوجيه نجح وأن الموقع يُفتح خلف Cloudflare؟ استخدم موقعاً للتحقق من عنوان IP العام من جهاز داخل الشبكة أثناء زيارة الموقع المستهدف فيجب أن يتطابق مع موقع خادم VPN. نجاح فتح منصة البث دون ظهور شاشة حجب LaLiga دليل عملي على أن القواعد تعمل. يمكنك أيضاً مراقبة رسم حركة الواجهة في pfSense للتأكد من أن التدفق يمر فعلياً عبر النفق.
ما أشهر الأخطاء أثناء الإعداد وكيف يمكن حلها؟ أشهرها نسيان تفعيل خيار بوابة النفق داخل القاعدة، فيبقى التدفق يخرج من الاتصال المحلي عبر IPv4 أو IPv6. خطأ شائع آخر هو عدم إضافة قاعدة NAT صحيحة لخروج الحزم أو إغفال تحديث الـ Alias بنطاقات CDN الجديدة التي يستخدمها الموقع. راجع سجل جدار الحماية لتتبع الحزم المرفوضة وعدّل القواعد وفق السجلات الرسمية حتى يعمل النفق باستقرار.