كيف يعمل WireGuard؟ شرح توجيه المفاتيح المشفّرة

كيف يعمل WireGuard، بفكرة واحدة

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

لا يوجد جدول جلسات يعتمد على عناوين IP، ولا قاعدة بيانات للمستخدمين. القرين هو مفتاح عام مضافاً إليه مجموعة العناوين التي يُسمح لذلك المفتاح باستخدامها. توجد المصافحة والمؤقتات للحفاظ على صحة هذا الربط أثناء تغيّر الشبكة الأساسية. إذا أردت إنشاء نفق يعمل قبل دراسة النظرية، فأنشئه باستخدام شبكة WireGuard VPN مستضافة ذاتياً على VPS خاص بك، ثم عد إلى هنا عندما يفاجئك أحد أسطر الإعداد.

AllowedIPs هو جدول توجيه وقائمة وصول

ابدأ باتجاه الخروج. يوجّه kernel الحزمة إلى جهاز wg0 بالطريقة المعتادة، عبر جدول التوجيه الرئيسي. بعد ذلك يطابق WireGuard عنوان وجهة الحزمة مع جدول واحد يحتوي على جميع البادئات المسموح بها لكل peer، مرتبة وفق أطول بادئة أولاً. تحدد المطابقة peer، الذي يحدد بدوره مفتاحاً عاماً، ثم مفتاح جلسة ونقطة نهاية UDP. تُشفَّر الحزمة لهذا الـpeer وتُرسَل إليه.

إذا لم تغطِّ AllowedIPs الخاصة بأي peer عنوان الوجهة، فلا تُرسَل أي بيانات، لأنّه لا يوجد مفتاح يمكن استخدامها للإرسال.

ping: sendmsg: Required key not available

يعني هذا الخطأ شيئاً واحداً: العنوان الذي حاولت الوصول إليه غير مدرج ضمن أي peer. أما الخطأ المختلف، ping: sendmsg: Destination address required، فيعني أن إحدى الـpeers طابقت العنوان، لكن WireGuard لا يملك نقطة نهاية لها، لأنّه لم يتم ضبطها ولم يتعلمها بعد.

ننتقل الآن إلى اتجاه الدخول. تصل حزمة UDP إلى منفذ الاستماع. يعثر WireGuard على الجلسة باستخدام فهرس المستقبل في الترويسة، ثم يتحقق من العداد مقابل نافذة إعادة تشغيل منزلقة، وبعد ذلك يفك تشفير الحمولة ويتحقق من صحتها. لا يقرأ الحزمة الداخلية إلا بعد ذلك، ويجب أن يقع عنوان مصدر هذه الحزمة الداخلية ضمن AllowedIPs الخاصة بالـpeer المرسل. إذا لم يقع ضمنها، تُسقَط الحزمة. عند تفعيل التصحيح الديناميكي، يطبع kernel السبب في سطر مثل هذا:

wg0: Packet has unallowed src IP (10.8.0.9) from peer 2 (203.0.113.10:51820)

لهذا يحصل peer على جانب الخادم على /32. يمكن لـpeer الذي تم ضبطه باستخدام AllowedIPs = 10.8.0.2/32 إرسال حزم من 10.8.0.2، ولا يمكنه إرسالها من أي عنوان آخر. استبدل ذلك بـ0.0.0.0/0، وعندها يُسمح لذلك العميل الواحد بحقن حزم تدّعي استخدام أي عنوان مصدر داخل نفقك، بما في ذلك عنوان عميل آخر.

تُحسم البادئات المتداخلة وفق درجة التحديد، لأن البحث يستخدم مطابقة أطول بادئة. أما البادئات المتطابقة لدى اثنين من الـpeers فتتصرف بشكل مختلف: ينتقل الإدخال إلى الـpeer الذي تم ضبطه أخيراً، ويتوقف الـpeer الأول عن تلقي تلك الحركة من دون طباعة أي خطأ في أي مكان. يطبع wg show wg0 allowed-ips الجدول الموجود فعلياً في kernel، وهو الجدول المعتمد عندما تختلف حالة الملف على القرص عن الحالة قيد التشغيل.

قراءة ملف إعداد مع مراعاة التوجيه باستخدام cryptokey

على جانب الخادم:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>

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

على جانب العميل:

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

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

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

نصف هذه المفاتيح ليس جزءاً من البروتوكول أصلاً. تنتمي Address وDNS وMTU وPostUp وSaveConfig إلى wg-quick، وهو shell script يشغّل الواجهة. لا يرى kernel هذه القيم مطلقاً. يعرض wg-quick strip wg0 ملف الإعداد المختزل الذي يحمّله فعلياً tool ‏wg، وهذه أسرع طريقة لرؤية هذا الفصل.

ما الذي تنفذه المصافحة فعلياً

مصافحة WireGuard هي Noise_IKpsk2 من Noise Protocol Framework. الجزء IK المهم لمسؤول النظام هو أن المفتاح العام الثابت للطرف المستجيب معروف مسبقاً للطرف البادئ، لأنه PublicKey في كتلة [Peer] لديك، بينما يرسل الطرف البادئ مفتاحه العام الثابت داخل الرسالة الأولى بشكل مشفّر. لذلك لا يوجد تبادل للشهادات ولا جولة ذهاب وإياب لتبادل الهوية. لا يستطيع مراقب سلبي معرفة المفتاح الذي يجري الاتصال، إلا إذا كان يملك المفتاح الخاص للطرف المستجيب.

تتطلب المصافحة جولة ذهاب وإياب واحدة. يبلغ حجم رسالة البدء 148 بايت، ويبلغ حجم الاستجابة 92 بايت، ثم تبدأ البيانات بالتدفق مباشرة. ينشئ كل طرف زوج مفاتيح Curve25519 مؤقتاً جديداً لكل مصافحة، وتُشتق مفاتيح الجلسة من سلسلة من نتائج Diffie-Hellman التي تخلط بين المفاتيح الثابتة والمؤقتة. ثم تُحذف المفاتيح الخاصة المؤقتة، ما يوفّر السرية الأمامية: إذا سجّل شخص ما حركة بياناتك اليوم وسرق المفتاح الخاص للخادم في العام المقبل، فلن يستطيع قراءة ما سجّله.

تحمل بداية المصافحة طابعاً زمنياً من نوع TAI64N، ويتذكر كل طرف أكبر طابع زمني رآه من الطرف الآخر، لذلك تُرفض بداية المصافحة المعاد تشغيلها. وتحمل حزم البيانات عدّاداً بطول 64 بت يُستخدم كـnonce، ويحتفظ الطرف المستلم بنافذة منزلقة من العدادات التي رآها مؤخراً، لذلك يمكن التعامل مع إعادة التشغيل وإعادة الترتيب الشديدة من دون حالة اتصال على نمط TCP.

لا تدوم مفاتيح الجلسة طويلاً، وتكون المؤقتات مضمّنة في البرنامج وليست قابلة للتهيئة.

[
  {
    "label": "REKEY_TIMEOUT",
    "seconds": 5,
    "notes": "resend a handshake initiation that got no answer"
  },
  {
    "label": "KEEPALIVE_TIMEOUT",
    "seconds": 10,
    "notes": "send a keepalive after receiving data and sending none back"
  },
  {
    "label": "REKEY_ATTEMPT_TIME",
    "seconds": 90,
    "notes": "give up on the handshake and report the peer as down"
  },
  {
    "label": "REKEY_AFTER_TIME",
    "seconds": 120,
    "notes": "sender begins a fresh handshake for a new session key"
  },
  {
    "label": "REJECT_AFTER_TIME",
    "seconds": 180,
    "notes": "the old session key is refused and traffic stops"
  }
]

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

لماذا لا يملك النظير دور عميل أو خادم

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

يمكن للنظير الذي يحتوي على endpoint مُعدّ أن يبدأ عملية المصافحة. أما النظير الذي لا يحتوي على endpoint، فينتظر ثم يتعرّف على عنوان الطرف الآخر ومنفذه من أول حزمة تجتاز المصادقة بنجاح. يُخزَّن endpoint الذي تعلّمَه النظير، ويُحدَّث كلما وصلت حزمة صالحة من عنوان جديد. هكذا تعمل إمكانية التجوال: يحافظ حاسوب محمول ينتقل من شبكة Wi-Fi إلى شبكة جوّال على النفق نفسه، لأن الجلسة تُعرَّف بالمفتاح والفهرس، لا بعنوان IP. لا يُعاد إنشاء أي اتصال، لأنه لم يكن هناك اتصال بالمعنى المستخدم في TCP أصلاً.

تنشئ الآلية نفسها حقيقة مهمة: يحتفظ النظير ذو العنوان العام دائماً بآخر عنوان IP عام معروف للطرف الآخر، وتعرضه wg show.

بدائيات ثابتة، ولا شيء قابل للتفاوض

لا توجد قائمة ciphersuite في WireGuard. يستخدم WireGuard ‏ChaCha20-Poly1305 للتشفير الموثَّق، وCurve25519 لتبادل المفاتيح، وBLAKE2s للتجزئة، وHKDF لاشتقاق المفاتيح. تستخدم كل عملية نشر هذه البدائيات نفسها، لذلك لا توجد مرحلة تفاوض لتحليلها، ولا مسار للرجوع إلى خيار أضعف. المقابل واضح: إذا تعرّضت إحدى هذه البدائيات للكسر، فالإصلاح هو إصدار جديد من البروتوكول بالكامل وتحديث الطرفين، وليس تغييراً في الإعدادات. يزيل هذا القرار وحده معظم الشيفرة ومعظم حالات الفشل التي ينطوي عليها نفق يستند إلى TLS، وهذا هو جوهر المقارنة في WireGuard مقابل OpenVPN.

لماذا لا يستجيب المنفذ لأداة الفحص

تحمل كل رسالة مصافحة حقلاً يُسمّى mac1. وهو رمز مصادقة للرسائل (MAC) يُحسَب على الرسالة باستخدام مفتاح مشتق من المفتاح العام الثابت للطرف المستجيب. لا يستطيع المُرسِل الذي لا يعرف ذلك المفتاح العام إنشاء mac1 صالح، ولذلك يُسقط المستقبل هذه الحزمة من دون إرسال أي رد على الإطلاق. لا يوجد خطأ، ولا إعادة ضبط، ولا رسالة ICMP.

والنتيجة الظاهرة هي أن فحص UDP لا يتلقى أي رد.

sudo nmap -sU -p 51820 vpn.example.com

يعرض nmap الحالة open|filtered، وهي الإجابة نفسها التي يعرضها لمنفذ تُسقطه قاعدة جدار ناري بصمت. ويتصرف المنفذ بالطريقة نفسها سواء كان WireGuard يستمع أم لا، على الأقل بالنسبة إلى أي طرف لا يملك مفتاحك العام مسبقاً.

يتولى حقل ثانٍ، mac2، التعامل مع ضغط هجمات حجب الخدمة. عندما يكون المستقبل تحت الحمل، يجيب عن طلب بدء صالح برسالة cookie من 64 بايت مرتبطة بعنوان المصدر للمرسل، ويرفض تنفيذ عمليات تشفير بالمفتاح العام المكلفة إلى أن يعيد المرسل إرسال تلك cookie. يثبت ذلك أن عنوان المصدر حقيقي قبل إنفاق أي موارد من وحدة المعالجة عليه، ولا تُفعَّل هذه الآلية إلا تحت الحمل.

لماذا يجعل 0.0.0.0/0 النظير مسارَك الافتراضي

بما أن AllowedIPs هو جدول التوجيه، فإن AllowedIPs = 0.0.0.0/0, ::/0 يعيّن كل وجهة لهذا النظير. هذا هو إعداد النفق الكامل بأكمله.

التوجيه الذي يجعل ذلك يعمل أكثر أهمية من السطر نفسه. قد يتسبب مسار افتراضي عادي عبر wg0 في حلقة، لأن حزمة UDP المشفّرة التي تحمل حركة الشبكة يجب أن تغادر الجهاز أيضاً، وستطابق مسارها الافتراضي نفسه. يتجنب wg-quick ذلك باستخدام التوجيه وفق السياسات. فهو يضع علامة fwmark على حزم WireGuard الصادرة، ويضع مسار النفق الافتراضي في جدول توجيه منفصل، ويضيف قواعد بحيث تصل حركة الشبكة التي لا تحمل علامة فقط إلى هذا الجدول. شغّل ip rule show وسترى النتيجة:

32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0xca6c lookup 51820
32766:	from all lookup main

القيمة 0xca6c هي 51820 بصيغة hex، و51820 هو أيضاً رقم الجدول. تجعل قاعدة suppress_prefixlength 0 الجدول الرئيسي يتجاوز مساره الافتراضي، ولذلك تظل المسارات المحددة، مثل مسار الشبكة المحلية، ذات أولوية، بينما تمرر بقية الحركة إلى جدول النفق. لا يحتاج النفق المنقسم إلى أي من ذلك؛ إذ تتحول قائمة أضيق مثل AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 إلى مسارات عادية في الجدول الرئيسي.

هناك أمر لا يعالجه النفق الكامل تلقائياً، وهو تحليل أسماء النطاقات، لأن محلل الأسماء الذي تعلّمه العميل من الشبكة المحلية يبقى عادةً مستخدماً، كما أن مساره يكون أكثر تحديداً. هذه مهمة منفصلة، وتتناولها DNS الذي يتسرّب خارج نفق WireGuard.

الغرض الفعلي من PersistentKeepalive

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

لا يمكن الوصول إلى نظير خلف NAT (ترجمة عناوين الشبكة) أو خلف جدار ناري ذي حالة من الخارج إلا أثناء وجود تعيين في ذلك الجهاز. وينشأ هذا التعيين بواسطة حزمة صادرة. تبدأ مدة صلاحية تعيينات UDP الشائعة من نحو 30 ثانية. عند انتهاء التعيين، يحذف الجهاز الوسيط الحزم القادمة من الجانب العام، وتبدو النفق متوقفاً حتى يرسل النظير خلف NAT شيئاً. يرسل PersistentKeepalive = 25 حزمة فارغة موثّقة كل 25 ثانية، وهي مدة أقل من أقصر مدة صلاحية شائعة، لذلك يبقى التعيين مفتوحاً.

اضبطه على النظير الموجود خلف NAT. لا يحتاج الخادم الذي يملك عنواناً عاماً ومنفذ UDP مفتوحاً إلى ذلك، وضبطه عليه يضيف حركة مرور فقط. لا تخلطه مع keepalive التلقائي، الذي يعمل بعد 10 ثانية من تلقي النظير للبيانات، إذا لم يكن لديه شيء يرسله في الاتجاه المعاكس. يكون ذلك مفعّلاً دائماً ولا يمكن ضبطه.

توجيه شبكة LAN عبر النفق ليس ميزة في WireGuard

لنفترض أن النظير B موجود على شبكة منزلية 192.168.50.0/24، وأن النظير A يجب أن يصل إليها. يجب أن تتفق حالتان منفصلتان، ولا تتولى WireGuard إلا واحدة منهما.

دور WireGuard: أضف 192.168.50.0/24 إلى AllowedIPs الخاص بـB على A. يتيح ذلك لـA توجيه البادئة إلى B، كما يتيح لـA قبول الحزم التي تحمل عناوين المصدر هذه من B. من دون ذلك، لا يملك توجيه cryptokey مفتاحاً للوجهة، ولا يملك صلاحية لعنوان المصدر.

دور النواة: على B، يجب أن تكون net.ipv4.ip_forward هي 1، وإلا فإن النواة تسقط كل حزمة مفككة التشفير لا تكون موجهة إلى B نفسه. يجب أن تسمح سلسلة forward في جدار B الناري بهذه الحركة. تحتاج الأجهزة الموجودة على LAN إلى مسار عودة باتجاه 10.8.0.0/24، أو يجب أن يطبّق B ترجمة عنوان المصدر حتى تعود الردود عبر B.

ينتهي دور WireGuard عندما يسلّم الحزمة المفككة التشفير إلى النواة. كل ما يحدث بعد ذلك هو توجيه وترشيح عاديان في Linux، ولذلك يظهر هذا الفشل في عدادات nft list ruleset أو في ip -s link show wg0، وليس في wg show. إذا كنت تفضّل إدارة النظائر عبر واجهة ويب، فإن تشغيل wg-easy في Docker ينشئ إدخالات النظائر نيابةً عنك، لكن قواعد التوجيه تبقى من اختصاص المضيف.

لماذا يعمل WireGuard داخل النواة

wg0 هو برنامج تشغيل لجهاز شبكة. تصل الحزم إليه عبر مكدس التوجيه المعتاد، وتُشفَّر في سياق softirq، ثم تخرج عبر مقبس UDP من دون أن تعبر إلى مساحة المستخدم. من هنا يأتي معدل النقل، ولهذا أيضاً يبقى حجم الوحدة قريباً من أربعة آلاف سطر من الشيفرة، وهو حجم صغير بما يكفي لمراجعتها ودمجها في Linux 5.6 الرئيسي في March 2020. تأتي Ubuntu 24.04 وDebian 13 بها، لذلك لا ينقص سوى حزمة wireguard-tools.

لاستخدامها كواجهة عادية نتائج عملية. يعرض tcpdump -ni wg0 الحزم الداخلية بنصها الصريح، بينما يعرض tcpdump -ni eth0 udp port 51820 الحزم الخارجية المشفّرة، وتوضح مقارنة الاثنين فوراً الاتجاه الذي فيه الخلل. يتعامل netfilter وتشكيل حركة الشبكة مع wg0 مثل أي وصلة أخرى. عندما لا تتوفر وحدة النواة، مثل بيئات المحاكاة الافتراضية للحاويات التي تشارك نواة المضيف، يطبّق wireguard-go البروتوكول نفسه في مساحة المستخدم عبر جهاز TUN، مع تكلفة فعلية في معدل النقل لأن كل حزمة تعبر حدود النواة مرتين.

ما الذي لا يحميك منه WireGuard

نموذج التهديد ضيق عن قصد، وبروتوكول هادئ كهذا قد يشجع على التوقعات غير الواقعية. اذكر حدوده بوضوح.

• لا يخفي أنك تستخدم WireGuard. لرسائل المصافحة أحجام ثابتة، وتحدد البايتة الأولى نوع الرسالة، ويستخدم النقل بروتوكول UDP. تتعرف عليه أدوات الفحص العميق للحزم بسهولة، ويمكن لشبكة لا تسمح باستخدام VPN حظره. لم تُضف الإخفاءية عن قصد.
• لا يخفي حجم البيانات أو توقيتها. لا تُحاذى الحمولة إلا إلى حد 16 بايت، لذلك يظل بإمكان المراقب معرفة وقت الإرسال وحجمه التقريبي.
• يحتفظ بآخر نقطة نهاية معروفة. يخزن النظير ذو العنوان العام عنوان IP العام الحالي للطرف الآخر، ويعرضه wg show. وبالاقتران مع عنوان نفق ثابت في الإعدادات، يصبح ذلك معرّفاً مستقراً يتبع المستخدم بين الشبكات. لا مشكلة في ذلك على VPS الخاص بك. وهذا أيضاً سبب إضافة الخدمات التجارية طبقة فوق البروتوكول.
• يصادق على مفتاح، وليس على شخص. الطرف الذي يملك ملف المفتاح الخاص هو النظير. اضبط /etc/wireguard على mode 700، واضبط ملفات المفاتيح على 600.
• لا توجد قائمة إبطال ولا مدة انتهاء. ينتهي الوصول عندما تحذف إدخال النظير من كل خادم يحتفظ به، وتظل المفاتيح الثابتة سارية حتى تزيلها.

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

FAQ

ما المقصود بالتوجيه باستخدام المفاتيح المشفّرة في WireGuard؟

التوجيه باستخدام المفاتيح المشفّرة هو القاعدة التي تربط كل حزمة بمفتاح عام. يحتوي كل إدخال لنظير على قائمة من البادئات في AllowedIPs. عند الإرسال، يختار WireGuard النظير بمطابقة وجهة الحزمة مع قائمة كل نظير، بدءاً من أطول بادئة، ولذلك تعمل القائمة كجدول توجيه. عند الاستقبال، بعد فك تشفير الحزمة والمصادقة عليها، يجب أن يقع عنوان المصدر الداخلي ضمن قائمة النظير نفسها، وإلا تُسقط الحزمة. لذلك تعمل القائمة كقائمة تحكم بالوصول أيضاً. لا يحتوي WireGuard على إعداد توجيه منفصل أو جدار ناري داخلي منفصل، لأن القائمة نفسها تؤدي الوظيفتين.

هل أحتاج إلى PersistentKeepalive على كلا النظيرين؟

لا. اضبطه على الطرف الموجود خلف NAT (ترجمة عناوين الشبكة) أو خلف جدار ناري ذي حالة، وهو عادةً العميل. لا يرسل WireGuard شيئاً أثناء الخمول، لذلك تنتهي صلاحية التعيين الذي يتيح للطرف البعيد الوصول إلى ذلك النظير، وغالباً يحدث ذلك خلال دقيقة، ثم تبدو القناة متوقفة في اتجاه واحد. يرسل PersistentKeepalive = 25 حزمة فارغة موثّقة كل 25 ثانية ويحافظ على التعيين مفتوحاً. لا يحتاج النظير الذي يملك عنواناً عاماً ومنفذ UDP مفتوحاً إلى ذلك.

لماذا يظهر عند تنفيذ ping عبر القناة الخطأ "Required key not available"؟

لأن عنوان الوجهة لا يقع ضمن AllowedIPs لأي نظير، ولذلك لم يجد التوجيه باستخدام المفاتيح المشفّرة مفتاحاً لتشفير الحزمة به، فرفض kernel إرسالها. شغّل wg show wg0 allowed-ips وقارن الناتج بالعنوان الذي تنفذ له ping. الخطأ المشابه Destination address required مشكلة مختلفة: تم العثور على نظير مطابق، لكن لا يملك WireGuard نقطة نهاية له، لأنه لم تُضبط أي نقطة نهاية ولم تصل بعد حزمة موثّقة من ذلك النظير.

هل يستطيع جدار ناري اكتشاف WireGuard وحظره؟

نعم. يصادق WireGuard على حركة الشبكة ويشفّرها، ولا يحاول إخفاء هويته. يبلغ حجم رسائل المصافحة 148 و92 بايتاً ثابتة، وتحدد البايتة الأولى من كل رسالة نوعها، كما أن النقل يتم عبر UDP، لذلك يستطيع فحص الحزم العميق تحديد البروتوكول بسهولة. وستوقفه الشبكات التي تحظر UDP أو تتعرف على بصمات البروتوكولات. يتطلب إخفاء القناة تغليفها داخل شيء آخر، وهذا يتطلب أداة منفصلة وليس إعداداً في WireGuard.