قرين WireGuard غير قابل للوصول بينما يعمل آخر: قائمة تحقق

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

الخطوة 1: اكتب المسار الذي يجب أن تسلكه الحزمة

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

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

الخطوة 2: قارن AllowedIPs على الجانبين، لا على جانب واحد

يستخدم WireGuard AllowedIPs كجدول توجيه وقائمة وصول في الوقت نفسه. عند الإرسال يُبحث عن العنوان الوجهة في AllowedIPs الخاصة بالقرين لاختيار النفق؛ وعند الاستقبال يجب أن يقع عنوان المصدر الداخلي داخل AllowedIPs الخاصة بالقرين المرسل وإلا تُسقط الحزمة. نطاق مفقود على أي جانب ينتج العَرَض نفسه: النقل يعمل والحمولة تختفي.

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

الخطوة 3: تحقق من عنوان المصدر الداخلي

العميل الذي يوجه 10.90.0.3 عبر wg0 لكنه يرسل الحزم من عنوان Wi-Fi الخاص به سيرفضه المستقبل، لأن المصدر لا يطابق AllowedIPs الخاصة بالقرين. تحقق مما تختاره النواة فعليًا بواسطة ip route get 10.90.0.3 from 10.90.0.2، وتحقق من العنوان المخصص لواجهة النفق بواسطة ip -brief addr show wg0.

على مضيف Linux المستقبل يكون ترشيح المسار العكسي بوابة ثانية. إن rp_filter صارمًا على الواجهة التي تملك مسار العودة قد يُسقط حركة النفق التي لا يطابق مسار عودتها الواجهة التي وصلت عبرها. افحص القيمة الفعلية قبل تعطيله؛ ففي كثير من الطوبولوجيات يكون الإصلاح الصحيح مسارًا، لا مرشحًا مخففًا.

الخطوة 4: راجع تمرير المحور ومسار العودة

إذا كان على المحور التمرير بين القرناء، فتحتاج النواة إلى net.ipv4.ip_forward=1، وعلى الجدار الناري أن يقبل التدفق الممرر: داخل على wg0، خارج على wg0، من عنوان نفق المرسل إلى عنوان المستقبل. ومن الأعطال الشائعة قاعدة إدخال تقبل UDP 51820 دون قاعدة تمرير]، فتنجح المصافحة وتموت الحمولة. اسرد القواعد الفعلية بواسطة sudo nft list ruleset أو ما يعادله في مدير الجدار الناري لديك.

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

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

الخطوة 5: غيّر شيئًا واحدًا وحافظ على القرين العامل سليمًا

أجرِ تغييرًا واحدًا على المسار الفاشل وأعد اختبار القرينين. استبدال AllowedIPs لكل قرين بـ 0.0.0.0/0 هو أسرع طريقة لكسر القرين الذي كان يعمل، لأنه يغير قرار التوجيه لكل حركة المرور على تلك الواجهة. حرر القرين الواحد، وأعد التحميل، واقرأ الحالة الحية مرة أخرى.

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