الأنفاق التي تعمل بينما يتوقف SSH إلى العنوان العام للخادم عن العمل تبدو كخادم يرفض الاتصال. على Windows يكون السبب الأرجح محليًا: إعداد AllowedIPs لنفق كامل من /0 يُفعِّل قواعد جدار حماية مقيِّدة تسمح بنقل النفق نفسه والقليل جدًا غير ذلك. الحزم المشفّرة التي تصل إلى ذلك العنوان لا تقول شيئًا عما إذا كان اتصال TCP منفصل إلى العنوان نفسه قد يخرج.

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

إذن التوجيه وإذن جدار الحماية أمران مختلفان

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

لهذا السبب قد ينجح traceroute إلى نقطة النهاية بينما تفشل محاولة SSH. الأول تحمله الخدمة التي تملك الاستثناء، والثاني لا.

ما الذي يفعله /0 على Windows

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

تلك القواعد هي الآلية الكامنة وراء عبارة kill switch. وهي تُنشَّط من شكل التكوين لا من مربع اختيار يحمل هذا الاسم.

الاستثناءات تغيّر نموذج الحماية

استبدال /0 ببادئتين نصف افتراضيتين هو الطريقة الموثقة للحفاظ على توجيه واسع دون الدلالات المقيِّدة، وهو نموذج حماية مختلف لا تهجئة أقصر. وطرح عنوان نقطة النهاية من البادئات المسموح بها هو الحل البديل الشائع الآخر، وهو يطيل القائمة ويغيّر أيضًا القواعد التي تُنشَّط. وليس أي منهما تعديلًا محليًا بأثر محلي. كل واحد منهما يحرّك الحدود لكل تدفق على الجهاز، لا فقط للاتصال الذي كنت تصلحه.

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

اختبر مسار الإدارة الذي اخترته

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

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

سجّل مسار الإدارة والعنوان المستخدم والسلوك عند سقوط النفق. هذه الملاحظة هي ما يمنع الشخص التالي من توسيع المسار الجانبي لتوفير خمس دقائق.

مقالات ذات صلة