كيف يعمل VPN؟ شرح فني للناس العاديين

كيف يعمل VPN؟ جهازك يبني نفقاً مشفراً لخادم تختاره، يرسل كل حزمة عبره، وذلك الخادم يوجه حركتك للوجهة الحقيقية باستخدام IP الخاص به. لأي شخص يراقب الشبكة بينك وبين خادم VPN، كل ما يرونه هو ضوضاء مشفرة تتجه لعنوان واحد. لأي شخص يراقب بعد خادم VPN، حركتك تبدو وكأنها جاءت من الخادم، لا منك.

تلك نسخة 30 ثانية. باقي هذا المنشور يفصل كل خطوة بتفاصيل البروتوكول الحقيقية، لأن "نفق مشفر" عبارة تخفي الكثير من الآلية المثيرة للاهتمام. سنغطي ما يحدث فعلاً أثناء VPN handshake، ما يعنيه التغليف على مستوى الحزمة، لماذا يجب أن يذهب DNS عبر النفق بشكل منفصل، كيف يعمل إخفاء IP (ليس سحراً، إنه NAT)، وكيف تختلف البروتوكولات الثلاثة الكبرى في سباكتها.

مكتوب للأشخاص الذين يريدون فهم النظام بدون شهادة شبكات.

نسخة 30 ثانية

تثبت عميل VPN وتضغط اتصال. خلف الكواليس:

العميل والخادم يجريان handshake. يثبتان من هما لبعضهما البعض ويتفقان على مفاتيح تشفير مشتركة. جولة أو جولتان.
نظام التشغيل يوجه الحركة إلى النفق. العميل يخبر نظام التشغيل "أرسل كل شيء عبر هذا المحول الشبكي الافتراضي." النفق الآن المسار الافتراضي.
كل حزمة تُشفَّر، تُلَفّ، وتُرسَل. الحزمة الأصلية (الموجهة لـ Wikipedia مثلاً) تُشفَّر وتوضع داخل حزمة خارجية جديدة موجهة لخادم VPN. من منظور الشبكة، تتحدث فقط مع خادم VPN.
الخادم يفك ويوجه. يفك تشفير الحزمة الداخلية، يرى Wikipedia كوجهة، ويرسلها بـ IP الخاص به كمصدر. Wikipedia ترد على الخادم، الذي يعكس العملية.
DNS يذهب عبر نفس النفق. البحث عن wikipedia.org يجري عبر النفق المشفر ويُحلّ في خادم DNS الخاص بمزود VPN، لا ISP.

تلك خط الأنابيب كله. الباقي تنوع في كيفية تنفيذ كل خطوة.

الخطوة 1: handshake وتبادل المفاتيح

التشفير يعمل فقط إذا اتفق الطرفان على مفتاح. handshake يؤسس ذلك المفتاح عبر شبكة حيث كل بايت قد يُراقب.

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

كل بروتوكول ينفذ هذا بشكل مختلف:

WireGuard. جولة واحدة. عميلك يرسل بدء بروتوكول Noise يحتوي على مفتاحك العام العابر وهويتك (مشفرة بمفتاح الخادم العام الثابت). الخادم يرد بمفتاحه العام العابر. كلا الجانبين يستخرجان مفاتيح جلسة متماثلة عبر HKDF ويبدآن إرسال البيانات. وقت handshake على شبكة سليمة: 100 ميلي ثانية أو أقل.

OpenVPN. TLS 1.2 أو TLS 1.3 handshake كامل، نفس الذهاب والإياب الذي يفعله المتصفح عند الاتصال بموقع HTTPS. ClientHello، ServerHello، تبادل الشهادات، تبادل المفاتيح، إنهاء. جولات أكثر، بايتات أكثر، وحدة معالجة أكثر. وقت handshake: 500 ميلي ثانية لأكثر من ثانية على شبكات أبطأ.

VLESS Reality. TLS 1.3 handshake لموقع شرعي حقيقي (هدف SNI). بروتوكول Reality يربط الاتصال تشفيرياً بشهادة TLS لذلك الهدف بينما يوجه الحركة لخادم VPN مختلف. لمراقب الشبكة، handshake لا يمكن تمييزه عن شخص يزور هدف SNI. مصادقة VPN تحدث داخل جلسة TLS عبر هوية UUID.

بعد handshake، كل جانب لديه مفاتيح جلسة متماثلة. التشفير المتماثل سريع؛ غير المتماثل (بمفتاح عام) بطيء. handshake يؤسس الجلسة المتماثلة الرخيصة بكفاءة. HTTPS يستخدم نفس النمط لنفس السبب.

الخطوة 2: التغليف، لا النفق المادي

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

تخيل حزمة IP عادية متجهة لـ Wikipedia. لها رأس (المصدر: جهازك، الوجهة: IP لـ Wikipedia) وحمولة (طلب HTTP). عندما يكون النفق قائماً، عميلك يأخذ الحزمة كلها، يشفرها، ويحشوها داخل حزمة خارجية جديدة موجهة لخادم VPN. الحزمة الأصلية الآن مخفية داخل المظروف الجديد.

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

هذه الحيلة (حزمة IP تغلف أخرى) هي الآلية وراء كل بروتوكول "tunneling" على الإنترنت. GRE، IPsec، WireGuard، OpenVPN: تنوعات على نفس الموضوع. التغليف يحدث في المحول الشبكي الافتراضي الذي يثبته عميل VPN (Wintun على Windows، TUN على Linux، utun على macOS). نظام التشغيل يرى واجهة شبكة عادية؛ عميل VPN يعترض كل حزمة موجهة هناك، يشفرها، ويرسل النتيجة عبر الشبكة الحقيقية.

الخطوة 3: التشفير في النقل

بمجرد أن ينتج handshake مفاتيح الجلسة، البروتوكول يستخدمها لتشفير كل حزمة من الحركة. اختيارات التشفير مهمة للأمن والأداء.

ChaCha20-Poly1305. تشفير تيار مع مصادقة مدمجة. سريع على الأجهزة بدون تسريع AES بالعتاد (الهواتف القديمة، الراوترات منخفضة الأداء). WireGuard يستخدم هذا حصرياً. OpenVPN يدعمه. ChaCha20 الافتراضي الحديث للبروتوكولات المصممة في العقد الماضي.

AES-256-GCM. نظير تشفير الكتل. تعليمات عتاد AES-NI على كل وحدة معالجة Intel وAMD منذ 2010 تجعل هذا أسرع خيار على عتاد سطح المكتب. الافتراضي الحديث لـ OpenVPN. WireGuard لا يستخدمه (مؤلفو WireGuard اختاروا ChaCha20 عمداً لتجنب اعتماد AES-NI للاستخدام المضمن).

AES-128-GCM. نفس العائلة، مفتاح أصغر. أسرع هامشياً، أقل بجنون البارانويا هامشياً. البروتوكولات الحديثة تتخلف افتراضياً لـ 256.

أجزاء "GCM" و"Poly1305" مهمة: إنها علامات مصادقة. التشفير وحده يخبرك أن المهاجم لا يستطيع قراءة حركتك؛ المصادقة تخبرك أن المهاجم لا يستطيع تعديلها بدون اكتشاف. VPN يشفر لكن لا يصادق معطل. كل بروتوكول حديث يستخدم تشفير مصادق (AEAD).

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

الخطوة 4: حل DNS عبر النفق

DNS هو النظام الذي يحوّل wikipedia.org إلى عنوان IP. افتراضياً، نظام التشغيل يرسل استعلامات DNS لأي محلل سلّمه DHCP، الذي عادةً ISP. هذا يحدث قبل أي حركة ويب.

بدون التعامل مع DNS، VPN يتسرب بشدة. تربط النفق، متصفحك يطلب من نظام التشغيل البحث عن bank.com، نظام التشغيل يرسل البحث لخادم DNS الخاص بـ ISP (خارج النفق)، وISP يحصل على قائمة بكل نطاق تزوره رغم أن النفق المشفر يفعل عمله للحركة الفعلية.

عميل VPN منفذ بشكل صحيح يوجه DNS عبر النفق. عدة آليات:

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

حجب تسريبات DNS عبر قواعد جدار حماية. على Windows، عميل VPN يستخدم مرشحات Windows Filtering Platform (WFP) لحجب استعلامات DNS على أي واجهة عدا النفق. حزام-وحمالات: حتى إذا حاول شيء ما إرسال استعلام DNS عبر الواجهة الخاطئة، جدار الحماية يسقطه.

تعطيل smart-multi-homed name resolution. Windows افتراضياً يرسل استعلامات DNS لواجهات شبكة متعددة بالتوازي ويستخدم أياً يستجيب أولاً. ميزة Windows هذه، تسمى SMHNR، تسرّب استعلامات DNS لمحلل ISP الأصلي في كل مرة تجريها، حتى مع VPN نشط. عميل VPN صحيح يعطل SMHNR عبر NRPT أو إدخالات registry.

حجب IPv6 إذا كان النفق IPv4 فقط. إذا كانت شبكتك تدعم IPv6 وVPN لا ينفق IPv6، استعلامات DNS لـ IPv6 تتخطى النفق كلياً. إما إنفاق IPv6 أو حجبه صراحة.

التعامل مع DNS هو حيث تفشل كثير من VPNs بطرق دقيقة. VPN يشفر الحركة لكن يسرّب DNS يسلم ISP نفس البيانات الوصفية التي سيكون لديهم بدون VPN.

الخطوة 5: إخفاء IP عبر NAT

عندما يوجه خادم VPN الحزمة الداخلية لـ Wikipedia، عليه اتخاذ خيار: كيف تعرف Wikipedia أين ترسل الرد؟

الإجابة هي Network Address Translation (NAT). خادم VPN يعيد كتابة IP المصدر للحزمة الصادرة من IP جانب-النفق الخاص بك إلى IP العام الخاص به، ويسجل الربط في جدول NAT. عندما ترد Wikipedia، الخادم يبحث عن الربط، يعيد كتابة الوجهة لـ IP النفق الخاص بك، يشفر الحزمة، ويعيدها عبر النفق. نفس NAT الذي يستخدمه راوتر منزلك، فقط على نطاق.

من منظور Wikipedia، مصدر طلبك هو IP العام لخادم VPN. Wikipedia لا تستطيع استنتاج IP منزلك من ذلك الاتصال. يستطيعون استنتاج أنك تستخدم VPN إذا تحققوا من IP مقابل قوائم مخارج VPN معروفة (معظم المواقع الكبيرة تفعل لاكتشاف الاحتيال)، لكن لا يستطيعون التعرف عليك تحديداً.

هذا يفسر أيضاً لماذا "IPs مشتركة" مزايا خصوصية وعيب قابلية استخدام. إذا كان مئات الأشخاص يخرجون عبر نفس IP، حركة لموقع معين لا يمكن أن تُنسب لأي منهم. الجانب السلبي: IPs المشتركة أكثر احتمالاً للإشارة أو تحديد المعدل من المواقع التي لا تثق بها (بعض البنوك، بعض captchas، بعض خدمات البث).

الخطوة 6: حيلة توجيه نظام التشغيل

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

العميل يضيف:

مسار افتراضي جديد عبر المحول الافتراضي (غالباً كمسارات منقسمة 0.0.0.0/1 و128.0.0.0/1 لتجاوز الافتراضي الموجود دون إزالته).
مسار محدد لـ IP خادم VPN عبر المحول المادي الأصلي، حتى تستطيع الحزم الخارجية المشفرة المغادرة فعلاً.
خادم DNS مضبوط على محلل جانب-النفق.

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

كيف تختلف البروتوكولات في السباكة

غطينا الهيكل المشترك. كل بروتوكول يملأ التفاصيل بشكل مختلف.

WireGuard. UDP فقط. handshake بحجم ثابت (148 بايت بدء، 92 بايت رد). ChaCha20-Poly1305 فقط. يتجول عبر الشبكات بأناقة لأن حالة الجلسة مفتاحها الهويات الثابتة، لا زوج IP/منفذ. تنفيذات userspace موجودة (boringtun، الذي يستخدمه Fexyn) لكن تنفيذات النواة متاحة أيضاً. وقت الاتصال هو الأدنى بين الثلاثة: تحت الثانية، غالباً تحت 500 ميلي ثانية دافئاً.

OpenVPN. UDP أو TCP. قناة تحكم مستندة لـ TLS، قناة بيانات منفصلة. تشفير قابل للتكوين (حديث: AES-256-GCM أو ChaCha20-Poly1305). userspace فقط، قاعدة كود أكبر، مقابض تكوين أكثر. handshake أبطأ، عبء لكل حزمة أكبر. مخضرم التوافق: يعمل على شبكات حيث WireGuard لا، خاصة في وضع TCP حيث الاتصال يبدو كتيار TCP مشفر عام.

VLESS Reality. TCP فقط. الهدف كله أن يبدو كـ HTTPS عادي لمراقب الشبكة. handshake هو TLS 1.3 handshake حقيقي لموقع شرعي حقيقي (مكوَّن كهدف SNI على كلا العميل والخادم). داخل جلسة TLS تلك، بروتوكول VLESS يحمل الهوية (UUID) والحركة. تدفق Vision (xtls-rprx-vision) الذي نستخدمه يضيف تأطيراً داخلياً منخفض العبء لحركة VPN. أبطأ من WireGuard لمعدل النقل الخام لكن يصمد في البيئات حيث WireGuard وOpenVPN محجوبان صراحة.

عميل حديث يختار لكل شبكة. شبكات سريعة، مفتوحة: WireGuard. شبكات تحجب WireGuard لكن تسمح TLS عام: VLESS Reality. شبكات تحجب كليهما لكن تسمح حركة OpenVPN-shaped: OpenVPN كآخر fallback. محرك دوران Fexyn يفعل هذا تلقائياً.

ما يراه ISP، مع VPN مفعَّل مقابل معطَّل

VPN معطل. ISP يرى IP لكل خادم تتصل به، النطاقات التي تبحث عنها عبر DNS، وكم تتدفق البيانات متى. لا يستطيعون قراءة محتوى HTTPS لكن يستطيعون قراءة SNI (النطاق في TLS handshakes)، الذي يعطيهم نفس رؤية النطاق من زاوية مختلفة.

VPN مفعَّل، عميل منفذ جيداً. ISP يرى IP واحد (خادم VPN)، بايتات مشفرة تتدفق إليه، وأنماط توقيت. استعلامات DNS تذهب عبر النفق، لذا ISP لا يستطيع قراءتها. SNI لم يعد مرئياً لحركتك الحقيقية، لأن TLS handshake الوحيد الذي يراه ISP هو لخادم VPN (أو لهدف SNI مع Reality، الذي عادةً موقع شائع لا يكشف شيئاً عن وجهتك). ISP يستطيع عادةً بصمة أنك تستخدم VPN، لكن ليس أي مواقع تزور عبره.

تحول الثقة مرئي في هذه القائمة. ISP يفقد كل ما لديه. مزود VPN يكتسبه. سياسة التسجيل وثقة المزود أهم من أي ميزة فنية واحدة.

عبء الأداء

VPN يضيف تكلفتين: عمل تشفير على وحدة معالجتك، وقفزة إضافية على مسار حركتك.

وحدة المعالجة. AES وChaCha20 الحديث يتحركان بعدة جيجابتس في الثانية على نواة واحدة. للإنترنت المنزلي النموذجي (تحت 1 Gbps)، عبء وحدة المعالجة غير مرئي.

الكمون. إضافة قفزة يضيف كموناً متناسباً مع المسافة الجغرافية بينك وخادم VPN والوجهة. مخرج قريب يضيف 5-20 ميلي ثانية؛ قفزة عبر القارات تضيف 100 ميلي ثانية أو أكثر. التصفح والبث يستوعبان هذا بخير؛ الألعاب التنافسية لا.

معدل النقل. WireGuard يضيف حوالي 60 بايت لكل حزمة (رؤوس IP/UDP الخارجية زائد علامة المصادقة)، تقريباً عبء تأطير 4% على MTU 1500 بايت. عبء OpenVPN أقرب لـ 10%. الضربة الفعلية لمعدل النقل عادةً أكبر من حسابات لكل حزمة لأن خادم VPN يمكن أن يكون عنق زجاجة إذا كان غير مناسب لعدد مستخدميه. في اختباراتنا، WireGuard يكلف 5-10% من إجمالي عرض النطاق على اتصال سليم؛ OpenVPN يكلف 15-25%. VLESS Reality يجلس بينهما بتباين أكثر بسبب تأطير TLS.

الخلاصة

VPN يعمل بتشفير وتغليف حركتك، إرسالها عبر خادم مختار، وتوجيهها للأمام بـ NAT. handshake يؤسس مفاتيح الجلسة. التغليف يجعل الراوترات ترى فقط الحزمة الخارجية. DNS، kill switch، وتغييرات جدول التوجيه تلتقط الحالات الحدية التي قد تسرّب هويتك الحقيقية للشبكة.

الآلية مفهومة جيداً وليست سحرية. فائدة الخصوصية تعتمد على أي طرف توجه عبره، وما يفعلونه بما يرونه. اختر بروتوكولاً مطابقاً لظروف شبكتك، مزوداً مطابقاً لمتطلبات ثقتك، وعميلاً يتعامل مع نواقل التسريب (DNS، IPv6، SMHNR، kill switch) بشكل صحيح.

أسئلة شائعة

حزم IP مشفرة، مغلَّفة. حزمتك الأصلية (بمصدرها ووجهتها الحقيقيين) مشفرة وموضوعة داخل حزمة خارجية جديدة موجهة لخادم VPN. لأي شخص يراقب الشبكة، الحزمة الخارجية كل ما يرونه.

خطوة handshake تستخدم تشفير المفتاح العام (X25519 في WireGuard، RSA أو ECDHE في TLS لـ OpenVPN وReality) لتأسيس مفاتيح جلسة متماثلة دون أن تعبر تلك المفاتيح السلك أبداً. بمجرد أن يكون لكلا الجانبين مفاتيح الجلسة، كل حزمة مشفرة بتشفير متماثل سريع (ChaCha20-Poly1305 أو AES-256-GCM) يتضمن مصادقة مدمجة.

بحوث DNS تحدث قبل حركة الويب ويمكن أن تتسرب بشكل مستقل عن النفق. افتراضياً، نظام التشغيل يرسل DNS لأي محلل سلّمه DHCP، الذي عادةً ISP. عميل VPN يجب أن يعيد توجيه DNS بنشاط للنفق ويحجب أي مسارات تسريب (Windows SMHNR، fallback لـ IPv6، DoH للمتصفح متجاوزاً DNS لنظام التشغيل).

TUN واجهة layer-3 افتراضية (IP)؛ TAP واجهة layer-2 افتراضية (Ethernet). VPNs تقريباً دائماً تستخدم TUN لأنها تحتاج فقط نقل حزم IP. TAP لحالات الاستخدام التي تحتاج محاكاة Ethernet، مثل ربط شبكات محلية.

نعم، غالباً. حزم WireGuard لها شكل قابل للتعرف؛ OpenVPN عبر UDP له رأس مميز. حتى الحركة المشفرة لها أنماط حجم وتوقيت يمكن لأدوات البصمة استخدامها. VLESS Reality الأكثر مقاومة لأنه يقلد TLS حقيقي لموقع حقيقي شائع. "مشفر" و"غير قابل للاكتشاف" مشاكل مختلفة.

بدون kill switch، نظام التشغيل يعود للمسار الافتراضي الأصلي وتتدفق الحركة بنص واضح من IP الحقيقي الخاص بك. مع kill switch، العميل إما يبقي جدول التوجيه يشير لبوابة النفق (غير الموجودة الآن) (الحركة تذهب لثقب أسود) أو يثبت قواعد جدار حماية تحجب كل الحركة حتى يعيد النفق الاتصال.

نعم، ضد مشغل الشبكة. نقطة وصول Wi-Fi ترى نفقاً مشفراً لخادم VPN. لا يستطيعون قراءة حركتك، رؤية أي مواقع تزور، أو حقن محتوى. HTTPS يحمي معظم هذا بالفعل؛ VPN يضيف دفاعاً متعدد الطبقات ويحمي البيانات الوصفية مثل SNI.

handshake أصغر (جولة واحدة مقابل عدة)، عبء أصغر لكل حزمة، قاعدة كود أبسط أسهل للتحسين، وتصميم تشفير واحد متعمد يتجنب عبء التفاوض. WireGuard صُمم في 2015 مع دروس البروتوكولات الأقدم في الذهن.

على الشبكة: لا. يرون بايتات مشفرة لخادم VPN، نفس ما سيراه ISP. على الجهاز: ربما. إذا كان جهاز عملك لديه برنامج إدارة شركة (MDM، EDR)، ذلك البرنامج يستطيع قراءة الحركة على مستوى نظام التشغيل قبل دخولها لـ VPN. خصوصية على مستوى الشبكة حقيقية؛ خصوصية على مستوى الجهاز تعتمد على الجهاز.