ما هو VPN؟ شرح الشبكة الخاصة الافتراضية من المشكلة إلى الأنواع والبروتوكولات

عندما تجلس في مقهى وتفتح حاسوبك على شبكة Wi-Fi العامة ثم تدخل إلى لوحة إدارة سيرفر الشركة، فإن كل حزمة Packet تخرج من جهازك تمر أولاً بجهاز Router لا تعرف من يديره، ثم بشبكة مزود الخدمة ISP، ثم بعدد من الشبكات في الإنترنت حتى تصل إلى السيرفر، وكل جهة من هذه الجهات تستطيع أن ترى من أين جاءت الحزمة وإلى أين تذهب، وإذا لم تكن مشفرة فهي تستطيع أن تقرأ ما فيها أيضاً. والمشكلة لا تقف عند المقهى، فلوحة الإدارة نفسها يجب أن تكون مفتوحة على الإنترنت حتى تصل إليها من هناك، وهذا يعني أنها مفتوحة لكل من يمسح الإنترنت بحثاً عن لوحات مكشوفة.

وهذه المشكلة لها وجوه كثيرة يعرفها كل من أدار شبكة أو سيرفراً: موظف يعمل من البيت ويحتاج إلى نظام داخلي لا يجب أن يراه العالم، وقاعدة بيانات Database لا تريد أن تفتح منفذها لأحد، وفرعان للشركة في مدينتين يحتاجان أن يعملا كأنهما شبكة واحدة، والحل الذي تلتقي عنده كل هذه الحالات هو الشبكة الخاصة الافتراضية Virtual Private Network، واختصاراً VPN.

وقد طبقنا هذا الحل عملياً في دليل شبكة خاصة مع WireGuard وواجهة wg-easy، أما هذا المقال فيبدأ من قبل ذلك بخطوة، أي من الفكرة نفسها، حتى تفهم ما الذي يحدث داخل النفق ولماذا نضبط كل إعداد كما نضبطه، وسوف نناقش في هذا المقال ما يلي:

• المشكلة التي يحلها VPN، والحلول الأولى التي تخطر على البال ولماذا لا تكفي.
• ما هو VPN، وكيف يعمل النفق Tunnel بفكرة الحزمة داخل الحزمة مع التشفير Encryption.
• المكونات والمصطلحات التي سوف تقابلها في كل أداة: الكلاينت Client والبوابة Gateway والمفاتيح Keys والواجهة الافتراضية Virtual Interface وAllowedIPs والنفق الجزئي والكامل وتسرب DNS وغيرها.
• أنواع VPN: الوصول عن بعد Remote Access، وربط موقعين Site-to-Site، وشبكات Mesh، وخدمات VPN التجارية للخصوصية، ثم نموذج Zero Trust.
• البروتوكولات WireGuard وOpenVPN وIPsec وما قبلها، والأدوات المتاحة، وأي نوع يناسب حالتك.
• تجربة عملية صغيرة بثلاثة Containers تريك النفق من الداخل، ثم أشهر الأخطاء الأمنية.

ما المشكلة التي يحلها VPN؟

لنفرض أن لديك سيرفراً في مكتب الشركة أو على VPS، وعليه نظام داخلي ولوحة إدارة Admin Panel وقاعدة بيانات، وأن فريقك يحتاج أن يصل إليها من خارج المكتب، فأمامك أربع مشكلات منفصلة يجمعها سبب واحد هو أن بياناتك تمر في شبكات لا تملكها:

• الطريق نفسه غير موثوق: شبكة Wi-Fi في المقهى أو الفندق أو المطار يديرها شخص لا تعرفه، وقد يشاركك فيها شخص يراقب الحركة Traffic، ومزود الخدمة يرى كل اتصالاتك، والحركة بين فرعين للشركة تعبر الإنترنت العام. وصحيح أن HTTPS يحمي محتوى صفحات الويب، ولكن ليس كل ما يمر بينك وبين السيرفر صفحات ويب، فهناك قواعد البيانات ومشاركة الملفات SMB والطابعات وأنظمة قديمة لا تعرف التشفير أصلاً.
• الخدمات الداخلية مكشوفة: حتى تصل إلى لوحة الإدارة من البيت يجب أن تنشر منفذها Port على العنوان العام، وكل منفذ تنشره يصبح هدفاً لعمليات المسح الآلي Automated Scanning التي تعمل على الإنترنت ليلاً ونهاراً، كما شرحنا في شبكات Docker وأفضل الممارسات.
• الموظف البعيد: الموظف الذي يعمل من البيت أو من السفر يحتاج أن يكون جهازه كأنه داخل المكتب، يرى الطابعة والسيرفرات والأنظمة الداخلية بعناوينها الخاصة Private IP Addresses.
• الفرعان: فرع الشركة وموقعها الرئيسي لكل منهما شبكة محلية LAN، والمطلوب أن يصل جهاز في الفرع إلى سيرفر في المقر كأنهما في الشبكة نفسها، دون أن يثبت كل موظف برنامجاً على جهازه.

والصورة التالية تبين الفرق بين الحالتين: حاسوب في مقهى يرسل بياناته مكشوفة إلى سيرفر ينشر منافذه للجميع، ثم الحاسوب نفسه وهو يرسل كل شيء داخل نفق مشفر إلى بوابة لا تفتح إلا منفذاً واحداً، والأدوات الإدارية خلفها في شبكة خاصة:

الحلول الأولى التي تخطر على البال، ولماذا لا تكفي

قبل أن نصل إلى VPN، لنمر على الحلول التي يبدأ بها أغلبنا، لأن فهم سبب فشلها هو الذي يجعلك تفهم لماذا صمم VPN بالشكل الذي هو عليه:

1. فتح المنفذ مع كلمة مرور قوية: وهو أسهل الحلول، فتنشر لوحة الإدارة على الإنترنت وتحميها بكلمة مرور طويلة. والمشكلة أن كلمة المرور تحميك من التخمين فقط، ولكنها لا تحميك من ثغرة في صفحة الدخول نفسها، ولا من إعداد خاطئ يترك اللوحة دون مصادقة Authentication، وكل يوم تظهر ثغرات في لوحات إدارة مشهورة يستغلها المهاجمون قبل أن يحدثها أصحابها.
2. السماح لعناوين محددة IP Allowlist: وهو أفضل من الأول، فتسمح لعنوان المكتب وعنوان بيتك فقط، كما في قسم قصر لوحات الإدارة على عناوين محددة. ولكن عنوان البيت يتغير عند أغلب مزودي الخدمة، وكثير من الاتصالات تعمل خلف CGNAT فيشترك عنوان واحد بين مئات المشتركين كما شرحنا في تشغيل خادمك من إنترنت المنزل، والموظف المسافر يأتي كل يوم من عنوان جديد، وبالتالي فإنك سوف تقضي وقتك في تعديل القائمة، ولن تحل مشكلة الطريق غير المشفر.
3. طرق المنافذ Port Knocking: وفكرته أن يبقى المنفذ مغلقاً حتى يرسل الكلاينت سلسلة اتصالات إلى منافذ محددة بترتيب سري، فيفتح السيرفر المنفذ لعنوانه. وهو يخفي المنفذ عن المسح العادي، ولكن السلسلة نفسها تمر مكشوفة ويمكن لمن يراقب الطريق أن يعيدها، ولا يضيف أي تشفير للحركة بعد ذلك، لذلك اعتبره حيلة للإخفاء وليس حماية.
4. نفق SSH لكل خدمة: وهو حل صحيح لمدير واحد يحتاج منفذاً واحداً، حيث يمر المنفذ مشفراً داخل اتصال SSH، وقد شرحنا أنواعه في ما هو النفق Tunnel في الشبكات. ولكنه لا يصلح لفريق كامل يحتاج عشرات الخدمات والطابعة ومشاركة الملفات، ولا يجعل الجهاز جزءاً من الشبكة.

وقد يتساءل البعض: وماذا عن Cloudflare Tunnel وأمثاله؟ والإجابة على ذلك أن هذه الأنفاق العكسية Reverse Tunnels مصممة لنشر خدمة للعموم من خلف NAT دون فتح منافذ، وهي وظيفة مختلفة شرحناها في مقال النفق نفسه، أما المطلوب هنا فهو العكس، أي ألا يرى الخدمة أحد سوى أجهزة فريقك. والحل الذي يجمع ما ينقص كل هذه الطرق، أي التشفير والمصادقة لكل جهاز والعناوين الخاصة وعدم كشف الخدمات، هو VPN.

ما هو VPN؟

الشبكة الخاصة الافتراضية VPN هي شبكة خاصة تبنيها فوق شبكة عامة لا تملكها، أي فوق الإنترنت، بحيث تتصل الأجهزة البعيدة ببعضها عبر أنفاق مشفرة فتتعامل كأنها موصولة بسلك واحد في غرفة واحدة. وكلمة خاصة تعني أن لا أحد خارج الشبكة يستطيع أن يقرأ ما يمر فيها أو أن يدخلها دون مفتاح، وكلمة افتراضية تعني أنه لا يوجد سلك حقيقي بين الأجهزة، وإنما برنامج يجعل الإنترنت يتصرف كأنه هذا السلك.

ولتقريب الفكرة تخيل أنك تريد أن ترسل وثيقة سرية إلى فرع الشركة عبر البريد العادي الذي يمر بأيد كثيرة، فتضع الوثيقة في ظرف مغلق بقفل لا يفتحه إلا الفرع، ثم تضع هذا الظرف داخل ظرف بريدي عادي مكتوب عليه عنوان الفرع، فموظفو البريد يرون الظرف الخارجي وعنوانه فقط ويوصلونه، والفرع وحده يفتح القفل ويقرأ الوثيقة بعنوانها الداخلي الأصلي. وهذا بالضبط ما يحدث في VPN، ويقوم على ثلاث أفكار:

• التغليف Encapsulation: الحزمة الأصلية بعناوينها الخاصة توضع كاملة داخل حزمة جديدة لها عناوين عامة يفهمها الإنترنت، أي حزمة داخل حزمة.
• التشفير Encryption: الحزمة الداخلية تشفر قبل أن توضع في الحزمة الخارجية، ويضاف إليها رمز تحقق Authentication Tag يكشف أي تعديل عليها في الطريق.
• المصادقة Authentication: لا يقبل الطرف الآخر أي حزمة إلا إذا أثبت مرسلها هويته بمفتاح أو شهادة، فلا يستطيع أحد أن يدخل الشبكة لمجرد أنه عرف عنوانها.

والصورة التالية تبين ما يحدث لحزمة ping واحدة يرسلها حاسوب متصل بالـ VPN إلى تطبيق في شبكة المكتب، والأرقام فيها من التجربة العملية في آخر المقال:

لاحظ في الخطوة الثالثة أن من يراقب الطريق يرى عنوانين عامين ومنفذ UDP وحجم الحزمة، أي أنه يعرف أن هذا الحاسوب يتحدث مع هذا السيرفر ومتى وبأي كمية، ولكنه لا يعرف إلى أي جهاز داخلي تذهب الحزمة، ولا ما فيها، ولا يستطيع أن يعدلها دون أن يكتشف السيرفر ذلك. ويجدر الانتباه إلى أن كلمة «نفق» في الشبكات أوسع من VPN، فهناك أنفاق تغلف الحزم دون أي تشفير مثل GRE وVXLAN، وأنفاق SSH، والأنفاق العكسية، وكلها مشروحة في ما هو النفق Tunnel في الشبكات، أما VPN فهو نفق يجمع التغليف مع التشفير والمصادقة.

المكونات والمصطلحات التي سوف تقابلها في كل أداة

كل أداة VPN تستخدم أسماء مختلفة قليلاً في واجهتها، ولكن المفاهيم خلفها واحدة، وإذا فهمتها هنا فسوف تقرأ إعدادات WireGuard وOpenVPN وIPsec دون صعوبة.

الكلاينت Client والسيرفر Server والبوابة Gateway والنظير Peer

الكلاينت هو البرنامج على جهاز المستخدم الذي يبدأ الاتصال، والسيرفر هو الطرف الذي ينتظر الاتصالات على منفذ معروف. وعندما يكون السيرفر هو باب الدخول إلى شبكة كاملة خلفه نسميه بوابة VPN Gateway، ويكون عادة سيرفراً في طرف الشبكة أو جهاز Router أو جدار حماية Firewall. أما WireGuard فلا يفرق أصلاً بين الكلاينت والسيرفر، وإنما يسمي كل طرف نظيراً Peer، والطرف الذي نسميه سيرفراً هو مجرد نظير له عنوان ثابت يصل إليه الآخرون، وهذا ما يجعل بناء شبكات Mesh عليه سهلاً كما سيأتي.

المصادقة Authentication والمفاتيح والمصافحة Handshake

قبل أن تمر أي بيانات يجب أن يثبت كل طرف هويته للآخر، وهناك أربع طرق شائعة تجدها وحدها أو مجتمعة:

• زوج المفاتيح Key Pair: مفتاح خاص Private Key يبقى على الجهاز ولا يخرج منه، ومفتاح عام Public Key تعطيه للطرف الآخر. وهذه طريقة WireGuard، حيث يعرف السيرفر كل جهاز بمفتاحه العام فقط، ومن لا يملك المفتاح الخاص المقابل لا يحصل على أي رد.
• الشهادات Certificates: وهي مفاتيح عامة موقعة من جهة إصدار Certificate Authority تديرها أنت، واختصاراً CA، فيثق السيرفر بأي جهاز يحمل شهادة موقعة منها، وتستطيع أن تلغي شهادة جهاز واحد عند فقدانه. وهذه الطريقة المعتادة في OpenVPN وIPsec في المؤسسات.
• المفتاح المشترك مسبقاً Pre-Shared Key: واختصاراً PSK، وهو سر واحد يعرفه الطرفان. وفي IPsec القديم يستخدم وحده أحياناً لكل الأجهزة، وهذا خطأ كبير لأن تسربه من جهاز واحد يكشف الجميع، أما في WireGuard فهو طبقة إضافية اختيارية فوق المفاتيح، وwg-easy يولد واحداً لكل جهاز.
• اسم المستخدم وكلمة المرور مع التحقق بخطوتين MFA: وتستخدمها حلول VPN المؤسسية لربط الدخول بحساب الموظف في دليل المستخدمين، وMFA هنا ضروري وليس رفاهية كما سيأتي في قسم الأخطاء.

وتسمى عملية التعارف هذه المصافحة Handshake، وفيها يثبت الطرفان هويتهما ويتفقان على مفاتيح جلسة Session Keys مؤقتة تشفر بها البيانات، وتتجدد هذه المفاتيح تلقائياً كل بضع دقائق، والسبب أن سرقة مفتاح جلسة واحدة لا تكشف إلا جزءاً صغيراً من الحركة. وفي مخرج الأمر wg show سوف تجد سطر latest handshake، وهو أول ما تنظر إليه عندما لا يعمل النفق.

الواجهة الافتراضية Virtual Interface والعنوان الافتراضي Virtual IP

عندما يتصل جهازك بالـ VPN يظهر فيه كرت شبكة جديد لا وجود له في الحقيقة، وهو الواجهة الافتراضية، واسمها في WireGuard عادة wg0، وفي OpenVPN tun0 أو tap0. والفرق أن واجهة TUN تنقل حزم IP أي تعمل في الطبقة الثالثة Layer 3، وهي المستخدمة في أغلب الحالات، أما TAP فتنقل إطارات Ethernet كاملة أي تعمل في الطبقة الثانية Layer 2، وتحتاجها فقط عندما يجب أن يكون الجهاز في نفس شبكة ال Broadcast مع الطرف الآخر، كبعض الألعاب والأنظمة القديمة.

ولهذه الواجهة عنوان خاص بها هو العنوان الافتراضي، ويأخذه الجهاز من مجموعة عناوين Address Pool تخصصها لشبكة VPN، مثل 10.8.0.0/24 في wg-easy، حيث يأخذ السيرفر 10.8.0.1 ويأخذ كل جهاز عنواناً بعده. واختر لهذه المجموعة نطاقاً لا يستخدمه أحد في شبكاتك، والسبب أن الموظف الذي تكون شبكة بيته 192.168.1.0/24 لن يصل إلى سيرفر في المكتب له نفس النطاق، لأن جهازه يظن أن العنوان موجود في البيت. وقد شرحنا العناوين الخاصة ونطاقاتها في مصطلحات الاستضافة الذاتية.

التوجيه Routing وAllowedIPs

ولكي تمر الحركة في الواجهة يحتاج النظام أن يعرف أي حركة يرسلها عبر wg0 وأي حركة يرسلها عبر الاتصال العادي، وهذا ما يحدده جدول التوجيه Routing Table. وفي WireGuard يبني wg-quick هذا الجدول من قيمة AllowedIPs في ملف الجهاز، فإذا كتبت فيها 10.0.10.0/24 أضاف مساراً Route يرسل كل حركة إلى هذه الشبكة عبر النفق، وسوف ترى هذا المسار بعينك في التجربة العملية.

ولهذه القيمة وجه آخر على السيرفر يسمى في توثيق WireGuard التوجيه بالمفتاح Cryptokey Routing، حيث يربط السيرفر كل مفتاح عام بالعناوين المسموح لها أن تأتي منه، فإذا وصلته حزمة من جهاز الموظف بعنوان مصدر غير عنوانه أسقطها، وبالتالي لا يستطيع جهاز داخل الشبكة أن ينتحل عنوان جهاز آخر.

النفق الجزئي Split Tunnel والنفق الكامل Full Tunnel

وأهم قرار تتخذه في AllowedIPs على جهاز المستخدم هو نوع النفق: هل تمر فيه حركة الشبكة الداخلية فقط، أم كل حركة الجهاز بما فيها تصفح الإنترنت؟ والصورة التالية تبين الفرق:

في النفق الجزئي تكتب شبكات المكتب وحدها، فيصل الموظف إلى الأنظمة الداخلية ويبقى تصفحه سريعاً ولا يحمل السيرفر حركته، وهو الخيار المناسب في أغلب حالات العمل. وفي النفق الكامل تكتب 0.0.0.0/0, ::/0، فتمر كل الحركة إلى السيرفر ثم تخرج منه إلى الإنترنت، وتراها المواقع قادمة من عنوان السيرفر، وهو الخيار المناسب على شبكات Wi-Fi العامة أو عندما تريد أن تمر كل حركة الأجهزة على فلتر الشركة. ولاحظ أن النفق الكامل يحتاج من السيرفر أن يمرر الحركة Forwarding ويترجم عناوينها NAT حتى تعود الردود إليه، وهي نقطة يخطئ فيها الكثيرون كما سيأتي. وتفاصيل ضبط ذلك في wg-easy في قسم النفق الكامل والجزئي من دليل WireGuard.

DNS داخل النفق، وتسرب DNS Leak

قبل أن يتصل جهازك بأي اسم مثل git.example.com فإنه يسأل سيرفر DNS عن عنوانه كما شرحنا في شرح DNS وسجلاته للمبتدئين، ولهذا السؤال مشكلتان في VPN. الأولى أن الأنظمة الداخلية لها أسماء لا يعرفها إلا سيرفر DNS الداخلي، فإذا بقي الجهاز يسأل سيرفر مزود الخدمة فلن يجد هذه الأسماء، لذلك تضع في إعداد الكلاينت سطر DNS يشير إلى سيرفر DNS داخل الشبكة. والثانية تسمى تسرب DNS DNS Leak، وهي أن تمر الحركة في النفق الكامل بينما تبقى أسئلة DNS تخرج من الاتصال العادي إلى مزود الخدمة، فيعرف المزود وشبكة المقهى كل اسم تزوره رغم أن الحركة نفسها مشفرة. والحل أن يرسل النفق الكامل DNS أيضاً عبره إلى سيرفر تثق به، وبعض التطبيقات تفرض ذلك، فتطبيق WireGuard على Windows مثلاً عندما يجد نفقاً كاملاً يمنع أي سؤال DNS إلا إلى السيرفرات المكتوبة في الإعداد.

العبور من خلف NAT والإبقاء على الاتصال Keepalive

أغلب الأجهزة تعمل خلف ترجمة العناوين NAT في Router البيت أو شبكة الجوال، وهذا يعني أنها تستطيع أن تبدأ اتصالاً خارجاً، ولكن لا أحد يستطيع أن يبدأ اتصالاً إليها، لذلك يجب أن يكون طرف واحد على الأقل، وهو السيرفر عادة، له عنوان عام ومنفذ مفتوح. وتسمى قدرة البروتوكول على العمل رغم NAT العبور من خلف NAT NAT Traversal، ففي IPsec مثلاً يغلف المعيار RFC 3948 حزم ESP داخل UDP على المنفذ 4500 حتى تعبر أجهزة NAT. والمشكلة الأخرى أن ال Router ينسى اتصال UDP بعد فترة قصيرة من الخمول، فلا تصل حزم السيرفر إلى الهاتف، والحل هو الإبقاء على الاتصال Keepalive، أي أن يرسل الجهاز حزمة صغيرة فارغة كل 25 ثانية مثلاً، وهذا ما يفعله سطر PersistentKeepalive = 25 في WireGuard كما يشرح دليل البدء السريع.

حجم الحزمة MTU باختصار

لكل شبكة حد أعلى لحجم الحزمة يسمى MTU، وهو 1500 بايت في أغلب شبكات Ethernet، ولأن النفق يضيف ترويسات Headers جديدة حول كل حزمة كما رأيت في الصورة، فإن الحزمة الداخلية يجب أن تكون أصغر حتى تتسع الحزمة الخارجية في الحد نفسه، لذلك يضبط WireGuard الواجهة افتراضياً على 1420. وإذا رأيت مواقع تبدأ في التحميل ثم تتوقف، أو اتصالات SSH تعمل وتنقطع عند نقل ملف، فخفض MTU إلى 1380 أو 1280 كما في قسم مشكلات MTU في دليل WireGuard.

مفتاح القطع Kill Switch

إذا انقطع النفق لثوان، بسبب تغيير الشبكة أو ضعف الإشارة، فإن الجهاز يعود افتراضياً إلى الاتصال العادي ويرسل حركته مكشوفة دون أن يشعر المستخدم، ومفتاح القطع Kill Switch هو قواعد جدار حماية على الجهاز تمنع أي حركة خارج النفق ما دام النفق مفعلاً، فإذا انقطع توقف الاتصال بدلاً من أن يتسرب. وتطبيق WireGuard على Windows يفعله تلقائياً مع النفق الكامل كما في توثيق التطبيق، وتطبيقات VPN التجارية تضعه عادة في الإعدادات.

والجدول التالي يجمع هذه المصطلحات مع مكانها في ملف WireGuard، حتى ترجع إليه عندما تقرأ أي إعداد:

أنواع VPN: من يتصل بماذا؟

كل شبكات VPN تقوم على النفق نفسه، والذي يختلف بينها هو من يقف في طرفي النفق، وهذا ما يحدد النوع الذي تحتاجه.

الوصول عن بعد Remote Access: الموظف إلى المكتب

وهو النوع الأشهر، حيث يثبت كل موظف تطبيق VPN على حاسوبه وهاتفه، ويفتح كل جهاز نفقه الخاص إلى بوابة واحدة في المكتب أو على VPS، فيأخذ عنواناً من مجموعة العناوين ويصل إلى الشبكة خلفها. والصورة التالية تبين ذلك بالخطوات:

ونقاط القوة في هذا النوع أنه بسيط ويفهمه الجميع، وأن البوابة هي الباب الوحيد الذي تحرسه، وأن إيقاف موظف يعني حذف مفتاحه فقط. أما نقطة الضعف فهي أن البوابة تصبح نقطة واحدة إذا توقفت توقف الجميع، وأن كل الحركة بين موظفين في مدينتين تمر عبرها حتى لو كانا يتحدثان مع بعضهما. وهذا النوع هو الذي بنيناه في دليل WireGuard مع wg-easy.

ربط موقعين Site-to-Site: الفرع إلى الفرع

هنا لا يثبت أحد من الموظفين أي برنامج، وإنما يقوم جهاز Router أو جدار حماية في طرف كل شبكة بفتح نفق دائم إلى الجهاز المقابل في الشبكة الأخرى، فإذا أرسل حاسوب في الفرع حزمة إلى عنوان في شبكة المقر، رأى Router الفرع أن هذا العنوان يقع في الطرف الآخر فأرسلها في النفق، وفكها Router المقر وأوصلها، كما في الصورة التالية:

وهذا النوع هو المعتاد لربط الفروع، أو لربط شبكة المكتب بشبكة خاصة في مزود سحابي، والبروتوكول الأكثر انتشاراً فيه هو IPsec لأنه مدعوم في كل أجهزة الشبكات التجارية، مع أن WireGuard أصبح شائعاً أيضاً. وشرطه الأهم أن تستخدم كل شبكة نطاق عناوين مختلفاً، والسبب أنه إذا كانت الشبكتان 192.168.1.0/24 فلن يعرف ال Router هل العنوان 192.168.1.20 في هذا الطرف أم في الآخر، لذلك خطط للعناوين قبل أن تحتاج الربط، وليس بعده.

شبكات Mesh: كل جهاز إلى كل جهاز

في النوعين السابقين تمر الحركة كلها عبر بوابة مركزية، أما في شبكة Mesh، وتسمى أيضاً الشبكة المركبة Overlay Network، فيتصل كل جهاز بكل جهاز آخر مباشرة. والصعوبة هنا أن كل جهاز يحتاج أن يعرف المفتاح العام وعنوان كل جهاز آخر، ومع عشرين جهازاً يصبح هذا مئات الإعدادات، لذلك تضيف هذه الحلول سيرفر تنسيق Coordination Server، وهو بحسب شرح Tailscale صندوق مشترك يترك فيه كل جهاز مفتاحه العام ومكانه الحالي، ويأخذ منه مفاتيح الأجهزة الأخرى وأماكنها. والصورة التالية تبين ذلك:

في الصورة أعلاه لاحظ التالي:

• محتوى الحركة لا يمر عبر سيرفر التنسيق إطلاقاً، وإنما يحمل المفاتيح العامة والعناوين وسياسات الوصول، والمفاتيح الخاصة لا تخرج من الأجهزة.
• الأجهزة تحاول أن تفتح أنفاقاً مباشرة حتى وهي خلف NAT، بتقنيات العبور التي ذكرناها، فإذا فشلت، كما مع بعض شبكات الجوال، مرت الحركة عبر سيرفر Relay، وتسميه Tailscale DERP، والحركة تبقى مشفرة بين الجهازين ولا يستطيع ال Relay قراءتها.
• إذا توقف سيرفر التنسيق فإن الأجهزة الحالية تبقى تتصل ببعضها حتى تنتهي صلاحية مفاتيحها، ولكن لا يمكن إضافة جهاز جديد ولا تجديد المفاتيح.
• العناوين في Tailscale من النطاق 100.64.0.0/10 كما في توثيقها، وهو نطاق CGNAT نفسه، لذلك نادراً ما يتعارض مع شبكة البيت أو المكتب.

ونقاط القوة في Mesh أنه لا توجد بوابة مركزية تحمل كل الحركة أو تتوقف بالجميع، وأن السيرفر في البيت خلف CGNAT يصبح متاحاً لأجهزتك دون أن تفتح منفذاً، وأن سياسات الوصول تكتب لكل جهاز أو مستخدم. أما نقاط الضعف فهي أن سيرفر التنسيق يصبح أهم جزء في الشبكة، فمن يتحكم به يستطيع أن يضيف أجهزة، لذلك إما أن تثق بالشركة التي تديره، أو أن تشغله بنفسك بأداة مثل Headscale.

خدمات VPN التجارية للخصوصية: ماذا تخفي فعلاً؟

عندما يسمع أغلب الناس كلمة VPN فإنهم يقصدون التطبيقات التجارية التي تعلن عن الخصوصية، وهذه في الحقيقة نفق كامل من جهازك إلى سيرفر تملكه الشركة، ثم تخرج حركتك من هناك إلى الإنترنت، ولا علاقة لها بالوصول إلى شبكتك أنت. وهل هذا يجعلك مجهولاً على الإنترنت؟ لا، والتفصيل في الصورة التالية:

ما يفعله هذا النوع بصدق هو أنه يخفي المواقع التي تزورها عن شبكة المقهى ومزود الخدمة، ويخفي عنوانك الحقيقي عن المواقع. وما لا يفعله أهم: فمزود VPN نفسه يرى كل ما كان يراه مزود الخدمة، وإذا كان يحتفظ بالسجلات Logs فهي عنده وليست عندك، والموقع ما زال يعرفك من تسجيل دخولك وملفات تعريف الارتباط Cookies وبصمة المتصفح Browser Fingerprint، ولا يحميك النفق من صفحة تصيد Phishing أو برنامج ضار على جهازك. لذلك إذا كان هدفك هو الحماية على شبكات Wi-Fi العامة فنفق كامل إلى سيرفرك أنت يعطيك الفائدة نفسها دون أن تسلم حركتك لشركة لا تعرفها، وهذا ما يتيحه دليل WireGuard.

Zero Trust وZTNA: لماذا لا يكفي «من دخل فهو موثوق»؟

هناك مشكلة رئيسية في الأنواع السابقة كلها، وهي أن VPN التقليدي يتحقق من المستخدم مرة واحدة عند البوابة، ثم يصبح جهازه داخل الشبكة يرى كل ما فيها، وهذا يشبه مبنى فيه حارس واحد عند الباب ثم كل المكاتب مفتوحة، فمن سرق بطاقة موظف واحد دخل إلى كل مكان. ونموذج انعدام الثقة Zero Trust، ويعرفه المعيار NIST SP 800-207، يقلب هذه الفكرة، فلا ثقة لأي جهاز لمجرد أنه داخل الشبكة، وإنما يتحقق النظام من هوية المستخدم وMFA وحالة الجهاز مع كل طلب، ولا يفتح له إلا التطبيقات التي تسمح بها سياسته، كما في الصورة التالية:

والتطبيق العملي لهذه الفكرة يسمى الوصول إلى الشبكة بنموذج انعدام الثقة Zero Trust Network Access، واختصاراً ZTNA، وله شكلان سوف تقابلهما. الأول لتطبيقات الويب، حيث يقف Proxy يعرف الهوية Identity-Aware Proxy أمام كل تطبيق ويطلب الدخول قبل أن يمرر أي طلب، وقد شرحنا ذلك على سيرفرك في حماية أي تطبيق باستخدام authentik Forward Auth، والخدمة المقابلة عند Cloudflare في قسم Zero Trust Access. والثاني لما ليس ويب، مثل SSH وقواعد البيانات، حيث تضيف شبكات Mesh سياسات وصول ACL لكل مستخدم وجهاز فوق الأنفاق، فلا يصل جهاز المحاسب إلا إلى سيرفر المحاسبة.

وقد يتساءل البعض: هل يعني هذا أن VPN انتهى؟ والإجابة أن Zero Trust ليس بديلاً عن التشفير، وإنما هو طريقة في توزيع الصلاحيات، وأغلب حلوله تستخدم أنفاق WireGuard أو TLS في الأسفل، والأسلوب العملي لفريق صغير أن تبقي VPN للوصول إلى الشبكة، ثم تضيف فوقه الجدار الناري لكل جهاز وتسجيل الدخول الموحد SSO أمام التطبيقات، حتى لا يكون الدخول إلى النفق مفتاحاً لكل شيء.

البروتوكولات: WireGuard وOpenVPN وIPsec وما قبلها

البروتوكول Protocol هو الطريقة التي يتصافح بها الطرفان ويشفران الحركة ويغلفانها، وأي بروتوكول تختاره يحدد المنافذ التي تفتحها والأجهزة التي تدعمه دون برامج إضافية.

• WireGuard: بروتوكول حديث مدمج في نواة Linux منذ الإصدار 5.6، وكوده صغير جداً، فـ الورقة البحثية للبروتوكول تذكر أنه مكتوب في أقل من 4000 سطر دون خوارزميات التشفير نفسها، وهذا يجعل مراجعته ممكنة مقارنة بقواعد الكود الضخمة في OpenVPN وIPsec. وخوارزمياته ثابتة لا تختارها، وهي Curve25519 وChaCha20-Poly1305 وBLAKE2s، فلا يوجد إعداد ضعيف قد تختاره بالخطأ، ولا يرد على أي حزمة لا تحمل مفتاحاً صحيحاً، فلا يكتشف منفذه بالمسح. ونقطة ضعفه أنه يعمل عبر UDP فقط كما تذكر صفحة القيود المعروفة، فقد تمنعه شبكات تسمح بـ TCP وحده، وأنه لا يدير المستخدمين ولا يوزع العناوين بنفسه، لذلك ظهرت فوقه أدوات مثل wg-easy وHeadscale.
• OpenVPN: بروتوكول قديم ومجرب، يستخدم TLS للمصافحة والشهادات، ويعمل في مساحة المستخدم User Space عبر واجهة tun أو tap، والمنفذ الافتراضي له بحسب دليله المرجعي هو 1194، ويعمل عبر UDP أو TCP، وهذا ما يجعله قادراً على المرور من شبكات صارمة عندما تشغله على 443/tcp. ونقاط ضعفه أنه أبطأ من WireGuard، وأن إعداده بالشهادات وخياراته الكثيرة يحتاج خبرة حتى لا تترك فيه إعداداً ضعيفاً.
• IPsec مع IKEv2: معيار من IETF يعمل في طبقة IP نفسها، حيث يتفاوض الطرفان عبر بروتوكول IKEv2 المعرف في RFC 7296 على المنفذ 500/udp، ثم تمر البيانات في حزم ESP، أو عبر 4500/udp عند وجود NAT. وقوته الكبرى أنه مدمج في Windows وmacOS وiOS وAndroid وفي كل أجهزة الشبكات وجدران الحماية التجارية، لذلك هو الأشهر في ربط الفروع، ولكن إعداده معقد وخياراته كثيرة، ولإعداده دليل كامل من NIST هو SP 800-77. والتطبيق مفتوح المصدر المعروف له على Linux هو strongSwan.
• L2TP/IPsec: بروتوكول قديم يضع نفق L2TP داخل IPsec، أي تغليفاً فوق تغليف، وما زال موجوداً في الأنظمة لأسباب التوافق، ولا يوجد سبب لاختياره في إعداد جديد.
• PPTP: أقدمها، ويعمل بحسب RFC 2637 على 1723/tcp مع حزم GRE، وطريقة المصادقة فيه MS-CHAPv2 كسرت منذ سنوات طويلة، كما في تحليل Schneier وMudge، وقد أزالته Apple من iOS 10 وmacOS Sierra. لذلك لا تستخدمه إطلاقاً، وإذا وجدته في جهاز Router قديم فأوقفه.

وستقرأ في مواقع الشركات مصطلحي SSL VPN وIPsec VPN كأنهما نوعان، والفرق في الحقيقة هو الطبقة التي يعمل فيها التشفير، فـ IPsec يعمل في طبقة IP ويحتاج منفذين وبروتوكول ESP قد تمنعه بعض الشبكات، أما SSL VPN فيعتمد على TLS نفسه الذي تعمل به مواقع HTTPS، مثل OpenVPN وكثير من الحلول التجارية التي تعمل من المتصفح أو عبر 443/tcp، فيمر من أي شبكة تسمح بتصفح الويب، ولهذا تفضله الشركات للوصول عن بعد بينما يبقى IPsec هو المعتاد بين الفروع.

والجدول التالي يلخص المقارنة:

الأدوات المتاحة

هذه أشهر الأدوات التي سوف تقابلها، مع رخصة كل منها، لأن كلمة «مفتوح المصدر» تستخدم أحياناً لما ليس كذلك، والفرق شرحناه في ما هي البرمجيات مفتوحة المصدر وتراخيصها:

• wg-easy برخصة AGPL-3.0: WireGuard مع واجهة ويب لإضافة الأجهزة ورموز QR، وهو الأنسب لفريق صغير، وشرحناه في دليل WireGuard.
• Headscale برخصة BSD-3-Clause: سيرفر تنسيق تستضيفه بنفسك لتطبيقات Tailscale، والتطبيقات نفسها مفتوحة المصدر في أغلبها برخصة BSD-3-Clause، أما خدمة التنسيق التي تديرها Tailscale فتجارية.
• NetBird: شبكة Mesh على WireGuard مع لوحة تحكم، وبرنامج الأجهزة برخصة BSD-3-Clause، أما أجزاء السيرفر فبرخصة AGPL-3.0.
• OpenVPN Community برخصة GPL-2.0 هو البرنامج نفسه، أما OpenVPN Access Server فمنتج تجاري بواجهة إدارة، وخطته المجانية لاتصالين فقط.
• Pritunl: واجهة إدارة لـ OpenVPN وWireGuard، وكوده منشور على GitHub ولكن رخصته تمنع إعادة التوزيع والاستخدام التجاري، لذلك فهو ليس مفتوح المصدر بالمعنى الصحيح.
• strongSwan برخصة GPL-2.0: تطبيق IPsec وIKEv2 على Linux، وهو المعتاد لربط موقعين أو للاتصال بأجهزة شبكات تجارية.
• OPNsense برخصة BSD-2-Clause: نظام جدار حماية وRouter، فيه IPsec وOpenVPN وWireGuard من الواجهة، وهو خيار مناسب ليكون البوابة في طرف شبكة المكتب.
• Firezone: حل ZTNA على WireGuard، والتطبيقات والبوابة فيه برخصة Apache-2.0، أما لوحة الإدارة فبرخصة Elastic License 2.0، ومستودعه يذكر أن الاستضافة الذاتية في الإنتاج غير مدعومة رسمياً.

وسوف نشرح هذه الأدوات واحدة واحدة في مقالات قادمة بإذن الله، وتجد ترتيبها في خريطة التعلم.

أي نوع تحتاجه؟

الجدول التالي يبدأ من حالتك، وليس من الأداة:

تجربة عملية: نفق WireGuard بين ثلاثة Containers

الكلام عن الحزم والمسارات يصبح أوضح عندما تراه في مخرج حقيقي، لذلك سوف نبني الآن على جهازك شبكة صغيرة من ثلاثة Containers: «حاسوب» في شبكة تمثل الإنترنت، و«سيرفر VPN» متصل بالإنترنت وبشبكة المكتب معاً، و«تطبيق» في شبكة المكتب لا يصل إليه أحد من الخارج، ثم نفتح نفقاً بين الحاسوب والسيرفر ونرى ما يحدث. ولاحظ أن عناوين شبكة «الإنترنت» هنا من النطاق 198.51.100.0/24 المخصص للتوثيق، وأننا لا ننشر أي منفذ على جهازك، فكل شيء يبقى داخل Docker. وتحتاج إلى Docker على Linux أو Docker Desktop، وإذا لم يكن مثبتاً فانظر تثبيت Docker على Ubuntu.

نبدأ بإنشاء الشبكتين، حيث يمنع الخيار --internal شبكة المكتب من أي اتصال بالخارج، ثم ننشئ الحاسوب والسيرفر والتطبيق:

docker network create --subnet 198.51.100.0/24 lab-vpn-internet
docker network create --internal --subnet 10.0.10.0/24 lab-vpn-office
docker run -d --name lab-vpn-server --cap-add NET_ADMIN --sysctl net.ipv4.ip_forward=1 --network lab-vpn-internet --ip 198.51.100.10 alpine:3.24 sleep 3600
docker network connect --ip 10.0.10.2 lab-vpn-office lab-vpn-server
docker run -d --name lab-vpn-laptop --cap-add NET_ADMIN --network lab-vpn-internet --ip 198.51.100.20 alpine:3.24 sleep 3600
docker run -d --name lab-vpn-app --network lab-vpn-office --ip 10.0.10.5 alpine:3.24 sleep 3600
docker exec lab-vpn-server apk add -q wireguard-tools iptables tcpdump
docker exec lab-vpn-laptop apk add -q wireguard-tools iptables tcpdump

الصلاحية NET_ADMIN تسمح لل Container بإنشاء واجهة wg0 وتعديل المسارات، والإعداد ip_forward يسمح للسيرفر بتمرير الحركة من النفق إلى شبكة المكتب. وقبل أن نفتح النفق، لنتأكد أن الحاسوب لا يصل إلى التطبيق، وأن جدول التوجيه فيه لا يعرف شبكة المكتب أصلاً:

docker exec lab-vpn-laptop ping -c 2 -W 1 10.0.10.5
docker exec lab-vpn-laptop ip route

والمخرج سوف يكون كما يلي:

2 packets transmitted, 0 packets received, 100% packet loss
default via 198.51.100.1 dev eth0
198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.20

الآن ننشئ زوج مفاتيح لكل طرف، حيث يحفظ الأمر المفتاح الخاص في ملف ويطبع المفتاح العام الذي نعطيه للطرف الآخر:

docker exec lab-vpn-server sh -c 'umask 077; wg genkey | tee /etc/wireguard/server.key | wg pubkey'
docker exec lab-vpn-laptop sh -c 'umask 077; wg genkey | tee /etc/wireguard/laptop.key | wg pubkey'

ثم نكتب ملف السيرفر /etc/wireguard/wg0.conf داخل lab-vpn-server، مع وضع المفتاح الخاص للسيرفر والمفتاح العام للحاسوب مكان القيم بين القوسين:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>
PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADE

[Peer]
# laptop
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

وملف الحاسوب /etc/wireguard/wg0.conf داخل lab-vpn-laptop:

[Interface]
Address = 10.8.0.2/24
PrivateKey = <laptop private key>

[Peer]
# office VPN server
PublicKey = <server public key>
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.8.0.0/24, 10.0.10.0/24
PersistentKeepalive = 25

في الإعداد أعلاه لاحظ التالي:

• السيرفر يعرف الحاسوب بمفتاحه العام فقط، ويقبل منه العنوان 10.8.0.2/32 وحده، وهذا هو التوجيه بالمفتاح الذي ذكرناه.
• الحاسوب يعرف أين يجد السيرفر من Endpoint، ويرسل عبر النفق شبكة VPN وشبكة المكتب فقط، أي أنه نفق جزئي، وكل ما عداهما يخرج من eth0 كالمعتاد.
• السطر PostUp يضيف قاعدة ترجمة العناوين MASQUERADE على واجهة شبكة المكتب eth1، فيرى التطبيق الحركة قادمة من السيرفر 10.0.10.2، وبالتالي يعرف أين يرسل الرد دون أن نعدل شبكة المكتب.

الآن نشغل النفق على الطرفين:

docker exec lab-vpn-server wg-quick up wg0
docker exec lab-vpn-laptop wg-quick up wg0

ويطبع wg-quick كل أمر ينفذه، والمخرج على الحاسوب سوف يكون كما يلي:

[#] ip link add dev wg0 type wireguard
[#] wg addconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.0.10.0/24 dev wg0

وهنا ترى كل ما شرحناه في قسم المكونات في خمسة أسطر: واجهة افتراضية جديدة، وعنوان افتراضي، وMTU قيمته 1420، ومسار إلى شبكة المكتب عبر النفق بناه wg-quick من AllowedIPs. والآن نجرب الوصول إلى السيرفر عبر عنوانه في النفق، ثم إلى التطبيق في شبكة المكتب:

docker exec lab-vpn-laptop ping -c 3 10.8.0.1
docker exec lab-vpn-laptop ping -c 3 10.0.10.5

والمخرج سوف يكون كما يلي:

64 bytes from 10.8.0.1: seq=0 ttl=64 time=7.333 ms
64 bytes from 10.8.0.1: seq=1 ttl=64 time=0.667 ms
64 bytes from 10.8.0.1: seq=2 ttl=64 time=0.544 ms
3 packets transmitted, 3 packets received, 0% packet loss

64 bytes from 10.0.10.5: seq=0 ttl=63 time=15.964 ms
64 bytes from 10.0.10.5: seq=1 ttl=63 time=10.330 ms
64 bytes from 10.0.10.5: seq=2 ttl=63 time=4.800 ms
3 packets transmitted, 3 packets received, 0% packet loss

لاحظ أن قيمة ttl في الرد من التطبيق هي 63 وليست 64، والسبب أن الحزمة عبرت جهازاً واحداً في الطريق هو سيرفر VPN. ولنر حالة النفق ومسارات الحاسوب:

docker exec lab-vpn-laptop wg show
docker exec lab-vpn-laptop ip route
docker exec lab-vpn-laptop ip route get 10.0.10.5
docker exec lab-vpn-laptop ip route get 1.1.1.1

والمخرج سوف يكون كما يلي، بعد اختصار المفاتيح العامة:

interface: wg0
  public key: p/Rs...6hE=
  private key: (hidden)
  listening port: 56874

peer: y2jW...NEw=
  endpoint: 198.51.100.10:51820
  allowed ips: 10.8.0.0/24, 10.0.10.0/24
  latest handshake: 5 seconds ago
  transfer: 860 B received, 948 B sent
  persistent keepalive: every 25 seconds

default via 198.51.100.1 dev eth0
10.0.10.0/24 dev wg0 scope link
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.2
198.51.100.0/24 dev eth0 proto kernel scope link src 198.51.100.20

10.0.10.5 dev wg0 src 10.8.0.2
1.1.1.1 via 198.51.100.1 dev eth0 src 198.51.100.20

في المخرج أعلاه لاحظ التالي:

• السطر latest handshake يعني أن الطرفين تعارفا بالمفاتيح، والسطر transfer يبين أن الحركة تمر في الاتجاهين.
• الحاسوب لم يحدد منفذاً، فاختار له النظام منفذاً عشوائياً هو 56874، أما السيرفر فيستمع على 51820 الذي كتبناه، وهذا ما يجعل الحاسوب يعمل خلف أي NAT.
• الأمر ip route get يجيب عن السؤال الأهم في أي مشكلة توجيه: من أين تخرج هذه الحزمة؟ فالحزمة إلى 10.0.10.5 تخرج عبر wg0، والحزمة إلى 1.1.1.1 تخرج عبر eth0 مباشرة، وهذا هو النفق الجزئي بعينه.

والآن نصل إلى فكرة الحزمة داخل الحزمة، حيث نراقب على السيرفر واجهتين في الوقت نفسه أثناء إرسال ping واحد: الواجهة eth0 التي تمثل الإنترنت، والواجهة wg0 التي تخرج منها الحزم بعد فك التشفير:

docker exec lab-vpn-server tcpdump -ni eth0 -c 2 udp port 51820
docker exec lab-vpn-server tcpdump -ni wg0 -c 2 icmp

والمخرج سوف يكون كما يلي، الأول من eth0 والثاني من wg0:

12:46:22.751408 IP 198.51.100.20.56874 > 198.51.100.10.51820: UDP, length 32
12:46:23.337363 IP 198.51.100.20.56874 > 198.51.100.10.51820: UDP, length 128

12:46:23.337835 IP 10.8.0.2 > 10.0.10.5: ICMP echo request, id 158, seq 0, length 64
12:46:23.338463 IP 10.0.10.5 > 10.8.0.2: ICMP echo reply, id 158, seq 0, length 64

في المخرج أعلاه لاحظ التالي:

• على الإنترنت لا يوجد أي أثر لعنوان التطبيق 10.0.10.5 ولا لكلمة ICMP، وإنما حزم UDP بين عنوانين عامين، وهذا كل ما تراه شبكة المقهى ومزود الخدمة.
• الحزمة الأولى بطول 32 بايت هي حزمة Keepalive فارغة، أي ترويسة WireGuard ورمز التحقق فقط، والثانية بطول 128 بايت هي حزمة ping نفسها: 84 بايت للحزمة الأصلية، تكمل إلى 96 قبل التشفير، ثم يضاف إليها 16 بايت ترويسة و16 بايت رمز تحقق.
• بعد فك التشفير تظهر على wg0 الحزمة الأصلية بعناوينها الخاصة كما أرسلها الحاسوب.

وإذا راقبت واجهة المكتب eth1 بالأمر tcpdump -ni eth1 -c 2 icmp فسوف تجد أن التطبيق يرى الحركة قادمة من السيرفر، وهذا أثر قاعدة MASQUERADE:

12:46:40.574012 IP 10.0.10.2 > 10.0.10.5: ICMP echo request, id 164, seq 0, length 64
12:46:40.574164 IP 10.0.10.5 > 10.0.10.2: ICMP echo reply, id 164, seq 0, length 64

ماذا يحدث عندما يخطئ شيء؟

بعد أن عمل النفق، لنكسره عمداً بطريقتين حتى تعرف شكل الخطأ عندما تراه. الأولى أن تكتب المفتاح العام للسيرفر في ملف الحاسوب بحرف واحد خاطئ، وهو خطأ سهل الحدوث عندما تنسخ المفتاح يدوياً، فيكون مخرج wg show على الحاسوب كما يلي:

peer: Y2jW...NEw=
  endpoint: 198.51.100.10:51820
  allowed ips: 10.8.0.0/24, 10.0.10.0/24
  transfer: 0 B received, 888 B sent
  persistent keepalive: every 25 seconds

لاحظ أن الحرف الأول من المفتاح كبير Y بدلاً من y، وأن السطر latest handshake غير موجود أصلاً، وأن الحاسوب أرسل 888 بايت ولم يستقبل شيئاً. وعلى السيرفر يظهر في tcpdump أن حزمة المصافحة وصلت فعلاً بطول 148 بايت، ولكن السيرفر لم يرد عليها، ولا توجد أي رسالة خطأ في أي مكان، والسبب أن WireGuard يتجاهل بصمت كل حزمة لا تطابق مفاتيحه. لذلك عندما ترى 0 B received دون مصافحة فراجع المفاتيح والمنفذ والجدار الناري بالترتيب، كما في قسم لا توجد مصافحة في دليل WireGuard.

والثانية أن يحاول الحاسوب انتحال عنوان آخر داخل النفق، فنضيف إلى واجهته عنواناً لم يعطه له السيرفر ونرسل منه:

docker exec lab-vpn-laptop ip addr add 10.8.0.99/24 dev wg0
docker exec lab-vpn-laptop ping -c 2 -W 1 -I 10.8.0.99 10.8.0.1

والمخرج سوف يكون كما يلي:

PING 10.8.0.1 (10.8.0.1) from 10.8.0.99: 56 data bytes
2 packets transmitted, 0 packets received, 100% packet loss

النفق نفسه سليم والمصافحة ناجحة، ولكن السيرفر أسقط الحزم لأن مفتاح هذا الحاسوب مسموح له بالعنوان 10.8.0.2 وحده. وهذا يبين الفرق الذي ذكرناه في دليل WireGuard: قيمة AllowedIPs على جهاز المستخدم للتوجيه فقط ويستطيع تغييرها، أما على السيرفر فهي قيد يطبقه السيرفر على كل حزمة.

وفي النهاية نحذف ما أنشأناه:

docker rm -f lab-vpn-server lab-vpn-laptop lab-vpn-app
docker network rm lab-vpn-internet lab-vpn-office

الأخطاء الأمنية الشائعة

VPN يحمي الطريق ويخفي الخدمات، ولكنه لا يحمي من كل شيء، وأغلب الحوادث المرتبطة به جاءت من طريقة استخدامه وليس من التشفير نفسه:

• VPN ليس برنامج حماية Antivirus: إذا كان جهاز الموظف مصاباً ببرنامج ضار فإن هذا البرنامج يدخل معه إلى الشبكة، والسبب أن النفق يوصل الجهاز كما هو، لذلك فإن حماية الأجهزة وتحديثها جزء من حماية الشبكة.
• النفق الكامل دون تمرير وترجمة عناوين: أشهر خطأ في الإعداد أن تختار النفق الكامل ثم تنسى تفعيل ip_forward أو قاعدة MASQUERADE على السيرفر، أو أن تضعها على الواجهة الخاطئة، فتنجح المصافحة ويصل الجهاز إلى السيرفر، ولكن الإنترنت لا يعمل. وهي الحالة التي يعالجها دليل WireGuard عندما يتصل ال Container بشبكتين، في قسم المصافحة ناجحة ولا يوجد إنترنت.
• الاعتماد على النفق الجزئي كقيد أمني: كما رأيت في التجربة، المستخدم يستطيع أن يغير AllowedIPs على جهازه متى شاء، لذلك إذا أردت أن تمنع موظفاً من شبكة ما فاكتب ذلك في جدار حماية على السيرفر، مثل الجدار الناري لكل جهاز في wg-easy.
• مفتاح واحد لعدة أشخاص: لا تقم بإعطاء ملف إعداد واحد لأكثر من جهاز، ولا مفتاح PSK واحد لكل الشركة، والسبب أنك لن تعرف من اتصل، ولن تستطيع إيقاف شخص واحد دون أن توقف الجميع.
• دون MFA: الحلول التي تعتمد على اسم المستخدم وكلمة المرور تصبح هدفاً لرسائل التصيد، وتحذير CISA عن أمان VPN في المؤسسات يذكر صراحة أن المؤسسات التي لا تستخدم MFA للوصول عن بعد أكثر عرضة لهذه الهجمات، وأن أجهزة VPN التي تعمل طوال الوقت يتأخر تحديثها.
• كشف واجهة إدارة VPN: واجهة wg-easy أو لوحة Access Server تتحكم في الشبكة كلها، فمن يدخلها ينشئ لنفسه جهازاً، لذلك لا تنشرها على الإنترنت، واتبع ما في قسم فتح واجهة الإدارة بأمان.
• نسيان حذف الموظف المغادر: كل جهاز لموظف غادر أو هاتف ضاع هو باب ما زال مفتوحاً، لذلك اجعل حذف مفاتيحه خطوة ثابتة في إجراءات خروج الموظف، وراجع قائمة الأجهزة كل شهر واحذف ما لم يتصل منذ مدة.
• تسرب DNS: تحقق بعد إعداد النفق الكامل من أن أسئلة DNS تمر عبره كما شرحنا، وإلا فإن حركتك مشفرة وأسماء المواقع التي تزورها مكشوفة.
• تأخير تحديث البوابة: بوابة VPN هي الجهاز الوحيد في شبكتك الذي يقبل اتصالات من أي مكان في العالم، لذلك فهي أول ما يبحث عنه المهاجمون عند ظهور أي ثغرة، فحدثها قبل أي جهاز آخر، وأغلق بقية منافذ السيرفر كما في تأمين خادم VPS من أول دخول.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• VPN شبكة خاصة فوق الإنترنت، وتقوم على ثلاث أفكار: التغليف أي حزمة داخل حزمة، والتشفير، والمصادقة لكل جهاز بمفتاح أو شهادة.
• فتح المنافذ مع كلمة مرور وقوائم العناوين وطرق المنافذ لا تحل مشكلة الطريق ولا مشكلة الخدمات المكشوفة، والحل أن تبقى الخدمات الداخلية دون منافذ عامة خلف بوابة واحدة.
• القيمة AllowedIPs تبني المسارات على جهاز المستخدم وتقرر النفق الجزئي أو الكامل، وعلى السيرفر هي قيد يمنع انتحال العناوين.
• Remote Access للموظفين، وSite-to-Site للفروع، وMesh عندما تريد أن تتصل الأجهزة ببعضها مباشرة أو تعمل خلف CGNAT، وخدمات الخصوصية التجارية تنقل ثقتك إلى مزودها ولا تجعلك مجهولاً.
• Zero Trust لا يلغي VPN، وإنما يمنع أن يكون الدخول إلى النفق مفتاحاً لكل شيء، فأضف الجدار الناري لكل جهاز وSSO أمام التطبيقات.
• WireGuard هو الخيار الأول لأي إعداد جديد، وOpenVPN عندما تحتاج TCP عبر شبكات صارمة، وIPsec مع أجهزة الشبكات التجارية وبين الفروع، وPPTP لا يستخدم إطلاقاً.
• مفتاح لكل جهاز، وMFA، وواجهة إدارة غير منشورة، وحذف فوري لمفاتيح من يغادر، وتحديث البوابة قبل أي جهاز آخر.

دليلشبكة خاصة مع WireGuard وواجهة wg-easyلا تحتاج لوحات الإدارة إلى أن تكون مكشوفة للإنترنت. ننشئ شبكة VPN خاصة باستخدام WireGuard وواجهة wg-easy، ونضيف إليها الأجهزة برمز QR، فلا يصل إلى أدواتك إلا أجهزة فريقك.دليلما هو النفق Tunnel في الشبكات؟ أنفاق SSH والأنفاق العكسية وGRE وVXLANكيف تصل إلى قاعدة بيانات لا تراها من الإنترنت، وتنشر خدمة من خلف CGNAT دون فتح منافذ، وتربط شبكتين، بأنفاق SSH وfrp وVXLAN مع أوامر ومخرجات حقيقية، ومتى تحتاج إلى VPN بدلاً منها.دليلتشغيل خادمك من إنترنت المنزل: CGNAT وDDNS وCloudflare Tunnelهل يمكنك تشغيل خدماتك من اتصال الإنترنت في منزلك؟ يشرح هذا الدليل كيف تعرف ما يسمح به اتصالك، ومتى يكفي توجيه المنافذ، ولماذا يكون Cloudflare Tunnel غالباً الحل الأسهل والأكثر أماناً.دليلكيف تحمي أي تطبيق ويب بصفحة دخول authentik عبر Forward Authلديك أداة داخلية لا تحتوي على صفحة دخول؟ يمكنك أن تضع أمامها صفحة دخول authentik مع المصادقة الثنائية، دون أي تعديل على التطبيق نفسه.دليلخدمات Cloudflare بكلمات بسيطة وبدائلها مفتوحة المصدرما الذي تقدمه كل خدمة من Cloudflare، من DNS والتخزين المؤقت وWAF إلى Tunnel وWorkers، وما المتاح منها مجاناً، وما البديل مفتوح المصدر الذي تشغله على سيرفرك، وأين يستبدلها فعلاً وأين لا يمكن استبدالها.دليلتأمين خادم VPS من أول دخول على Ubuntu 24.04استلمت خادمك للتو؟ قبل أن تثبت عليه أي تطبيق، اتبع هذه الخطوات لإغلاق أبرز الثغرات: الدخول بمفتاح SSH بدلاً من كلمة المرور، وجدار حماية، وتحديثات أمنية تلقائية.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ مثال WireGuard بثلاثة Containers على Alpine 3.24 وwireguard-tools v1.0.20260223.