نفق WireGuard الكامل: AllowedIPs 0.0.0.0/0 لا يكفي

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

ما تختاره بادئة النظير، وما لا تختاره

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

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

توجيه العميل، لا قائمة النظير فقط

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

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

تفصيلان يحملان العمل. حقل Address هو بادئة مضيف واحدة بدلًا من شبكة فرعية يظن العميل أنه يملكها، والمدير هو الذي يحول AllowedIPs الافتراضي إلى مسار افتراضي فعلي. ارفع الملف نفسه باستخدام ip link و wg setconf فلن تظهر أي مسارات على الإطلاق، وهو ما يبدو نفقًا معطلًا بينما هو نفق سليم مع تخطي خطوة التوجيه. دليل wg-quick يوثّق التوجيه و Table السلوك الذي تضيفه هذه المديرون.

اقرأ النتيجة بدلًا من الملف: ip route get 1.1.1.1 يجب أن يسمي واجهة النفق، و wg show يجب أن يعرض مصافحة حديثة مع عداد نقل يتحرك. مصافحة بلا مسار تعني أن المدير لم يعمل أبدًا، وتعديل الملف الشخصي مرة أخرى لن يصلح ذلك. ابدأ الواجهة بالطريقة التي سيبدأها بها المستخدم، وإلا فإن الاختبار يقيس صدفتك بدلًا من النشر.

إبقاء نقطة النهاية خارج النفق

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

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

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

إعادة التوجيه ومسار الرد على البوابة

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS وحالة الفشل، مختبرين منفصلين

البروتوكول نفسه لا يضبط محلل أي تطبيق. wg-quick يطبق سطر DNS عبر تكامل المحلل في التوزيعة، وقد تتجاهله الحاويات والمتصفحات ذات المكدسات الخاصة بها، ولذلك قد يفشل الاسم بينما ينقل النفق الحزم بشكل مثالي. اختبر باسم مضيف لا بعنوان، ولاحظ أي خادم أجاب بدلًا من افتراض أن الخادم الموجود في الملف الشخصي هو الذي أجاب.

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

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