كيف يعمل WireGuard: شرح cryptokey routing

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

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

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

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

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

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

ping: sendmsg: Required key not available

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

والآن اتجاه الدخول. تصل حزمة UDP إلى منفذ الاستماع. يعثر WireGuard على الجلسة من receiver index الموجود في الترويسة، ويفحص العداد مقابل نافذة منع إعادة التشغيل المنزلقة، ثم يفك تشفير الحمولة ويتحقق من صحتها. بعد ذلك فقط يقرأ الحزمة الداخلية، ويجب أن يقع عنوان المصدر لهذه الحزمة الداخلية ضمن AllowedIPs الخاصة بـpeer المرسل. إذا لم يقع ضمنها، تُسقط الحزمة. عند تفعيل dynamic debug، يطبع 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 بدلاً من ذلك، وسيُسمح لهذا العميل الواحد بحقن حزم تدّعي استخدام أي عنوان مصدر داخل النفق، بما في ذلك عنوان عميل آخر.

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

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

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

[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 الذي يفعّل الواجهة. لا تصل هذه المفاتيح إلى النواة أبداً. يطبع wg-quick strip wg0 إعدادات التهيئة المختصرة التي يحمّلها فعلياً البرنامج 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 كعمر نسبي، ولهذا يحافظ النفق السليم والمشغول على عمر صغير. أما ازدياد العمر أثناء إرسال حركة شبكية فعلياً، فيعني أن المصافحات تفشل، وليس أن النفق خامل.

لماذا لا يملك الـpeer دور عميل أو خادم

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

يمكن للـpeer الذي يضم endpoint مُعدّاً أن يبدأ عملية handshake. أما الـpeer الذي لا يضم endpoint، فينتظر ثم يتعرّف على عنوان الطرف الآخر ومنفذه من أول packet تتم مصادقته بنجاح. يُخزَّن هذا الـendpoint المكتشف، ويُحدَّث كلما وصلت packet صالحة من عنوان جديد. هكذا تعمل ميزة التجوال: يحافظ laptop ينتقل من wifi إلى شبكة محمولة على النفق نفسه، لأن الجلسة تُحدَّد باستخدام key وindex، لا باستخدام عنوان IP. لا يحدث أي reconnect، لأنه لم يحدث اتصال بالمعنى الخاص بـTCP من الأساس.

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

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

لا توجد قائمة لمجموعات التشفير في 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 بالنظام الست عشري، و51820 هو أيضاً رقم الجدول. تجعل قاعدة suppress_prefixlength 0 الجدول الرئيسي يتجاوز مساره الافتراضي الخاص، لذلك تظل المسارات المحددة، مثل الشبكة الفرعية المحلية، هي المطبقة أولاً، بينما تنتقل كل الوجهات الأخرى إلى جدول النفق. لا يحتاج النفق المنقسم إلى أي من ذلك؛ إذ تتحول قائمة أضيق مثل AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 إلى مسارات عادية في الجدول الرئيسي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

هل أحتاج إلى PersistentKeepalive على كلا الـpeerين؟

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

لماذا يقول ping عبر النفق: "المفتاح المطلوب غير متاح"؟

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

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

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