خطأ 789 في L2TP/IPsec على Windows: أنشئ الملف الشخصي وثبّت المقترح
يفشل الخطأ 789 في تبادل IPsec، لا عند كلمة المرور. أنشئ ملف L2TP عبر سكربت، وثبّت المقترح، واقرأ الأكواد اللاحقة حسب المرحلة.
يعني الخطأ 789 على اتصال L2TP في Windows أن النفق قد مات داخل تبادل أمان IPsec، وهو ما يحدث قبل أن يرسل Windows أي كلمة مرور مستخدم إلى أي مكان. إعادة محاولة كلمة المرور، أو إعادة تعيينها في الدليل، لا يمكنها دفع تلك المرحلة قدماً. الذي يدفعها فعلاً هو إعادة بناء الاتصال من PowerShell بالمقترح الذي تقدمه البوابة فعلاً، لأن معالج الإعدادات يختار تحويلات IPsec بصمت ولا يظهر لك أبداً ما اختاره. هذا هو دليل التشغيل لذلك: أنشئ الملف الشخصي، وثبّت المقترح، ثم استخدم جدول مراحل حتى يخبرك الكود التالي بشيء.
أنشئ الملف الشخصي بدون المعالج
Add-VpnConnection يكتب إدخال دفتر هاتف أصلي، لذا تكون النتيجة هي الكائن نفسه الذي يعدله تطبيق الإعدادات لاحقاً. شغّله من جلسة مرتفعة عندما يجب أن يوجد الاتصال لكل حساب على الجهاز، أو من سياق المستخدم عندما يجب أن يبقى خاصاً:
Add-VpnConnection -Name "Contoso L2TP" `
-ServerAddress 203.0.113.10 `
-TunnelType L2tp `
-EncryptionLevel Required `
-AuthenticationMethod MSChapv2 `
-RememberCredential -Forceطابق -AuthenticationMethod مع ما تقدمه البوابة. MSChapv2 وEAP وPAP ليست قابلة للتبادل، والملف الشخصي الذي يطلب طريقة لن يقبلها الخادم يفشل قبل استشارة أي سجل مستخدم. أبقِ -EncryptionLevel Required لأي شيء حقيقي؛ Optional يسمح لـ Windows بقبول نفق غير مشفر إذا عرضه الطرف الآخر، وهو اختصار مختبري وليس إعداداً يُشحن.
إذا مررت -L2tpPsk، فسيُكتب ذلك المفتاح المشترك مسبقاً في الملف الشخصي على القرص، حيث يمكن لأي شخص يستطيع قراءة الملف الشخصي على ذلك الجهاز استرداده. استخدم شهادة لمصادقة الطرف الآخر عندما تدعمها البوابة، وعندما يكون PSK لا مفر منه، أبقِه بعيداً عن المستودع وعن سجل الصدفة بدلاً من لصقه في كل عملية تزويد.
ثبّت المقترح بدلاً من قبول الإعدادات الافتراضية
يملأ Windows تحويلات IPsec بنفسه، ولهذا يمكن لجهازين بما يبدو اتصالاً متطابقاً أن يفشلا بشكل مختلف ضد البوابة نفسها. Set-VpnConnectionIPsecConfiguration هو الطريقة المدعومة لتثبيتها:
Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
-AuthenticationTransformConstants SHA256128 `
-CipherTransformConstants AES128 `
-EncryptionMethod AES128 `
-IntegrityCheckMethod SHA256 `
-DHGroup Group14 `
-PfsGroup None `
-PassThru -Forceتلك المجموعة ترتيب L2TP/IPsec شائع، وليست إجابة عالمية. كل معامل يقبل قائمة قيم ثابتة، والتركيبة التي لا تستطيع المنصة تعيينها تعود كخطأ في cmdlet بدلاً من ملف شخصي مُضعَّف بهدوء. عامل مثل هذا الخطأ كبيان عن القيم، لا عن أذوناتك.
انسخ المقترح من وثائق البوابة أو من إعدادات الطور 1 والطور 2 الحية لديها، وغيّر حقلاً واحداً في كل مرة فقط بينما تسجل البوابة التحويلات التي ترفضها. الدوران عبر خمسة حقول ينتج اتصالاً يعمل بالمصادفة وسجلاً لا يشرح شيئاً للشخص التالي.
اقرأ الفشل حسب المرحلة، لا حسب نص الخطأ
ينتمي 789 إلى عائلة أكواد تبدو كلها متشابهة في مربع حوار العميل. ضع الكود مقابل المرحلة التي ينتمي إليها قبل أن تلمس الملف الشخصي مرة أخرى:
| What you see | Stage that failed | Check first |
|---|---|---|
| Nothing happens, then a timeout | No IKE response at all | Server address, UDP 500 and 4500 reachability, NAT traversal on the gateway |
| Error 789 | IKE security exchange | Proposal, pre-shared key, certificate trust and client clock |
| Error 691 or a repeated password prompt | User authentication | Account state, domain, RADIUS or NPS policy |
| Tunnel up, some hosts unreachable | Routing or DNS after PPP | Split-tunnel routes, pushed DNS, remote subnet mask |
دورا بيانات الاعتماد يهمان هنا. المفتاح المشترك مسبقاً أو الشهادة تصادق الطرفين على بعضهما، بينما MSChapv2 أو EAP يصادقك داخل النفق. إعادة تعيين كلمة مرور مستخدم لا تصلح الأول، وسر مشترك جديد لا يصلح الثاني، وتغيير كليهما معاً يدمر الدليل على أيهما كان مخطئاً.
على مسار الشهادة، تحقق من ساعة العميل وسلسلة الثقة والهوية التي تتوقعها البوابة قبل أن تفكر في تخفيف التحقق. تعطيل التحقق يحول 789 المرئي إلى نفق يتصل وهو يثق بالطرف الخطأ، ولن يخبرك شيء في العميل أن ذلك حدث. قائمة أخطاء الوصول عن بعد من Microsoft هي المرجع للأكواد نفسها، وهي تفصل إخفاقات طبقة الأمان عن إخفاقات تسجيل الدخول.
تحقق من الطرفين قبل أن تعلن الإصلاح
اقرأ الملف الشخصي مرة أخرى، لكن لا تتوقع رؤية المقترح في المخرجات. Get-VpnConnection يبلّغ عن الاسم وعنوان الخادم ونوع النفق ومستوى التشفير وطريقة المصادقة، ولا يعرف شيئاً عن التحويلات، لذا تؤكد القراءة أن الإدخال موجود ويشير إلى المضيف الصحيح:
Get-VpnConnection -Name "Contoso L2TP" |
Select-Object Name, ServerAddress, TunnelType, EncryptionLevel, AuthenticationMethodاتصل من سطر الأوامر لتحصل على رقم بدلاً من مربع حوار: rasdial "Contoso L2TP" يعيد رمز الفشل نفسه الذي تعيده الواجهة، و rasdial "Contoso L2TP" /disconnect يمسحه بين المحاولات. ثم اقرأ جانب البوابة لتلك المحاولة نفسها. ipsec statusall من strongSwan أو سجل IKE في الموجه يذكر أي مقترح وصل وأيها رُفض، ومقارنة ذلك بقيم cmdlet هي الخطوة الوحيدة التي تثبت فعلاً أن الطرفين اتفقا.
الاتصال الناجح ليس خط النهاية. افتح التطبيق الذي يهم المستخدم، لأن المسارات وDNS المدفوع وإعدادات النفق المنقسم تفشل بعد قيام النفق ولا تنتج أي مربع حوار خطأ.
أتمته، وتراجع بنظافة
الإعداد غير المراقب هو سبب كتابة سكربت لهذا، وخطوة الاتصال هي حيث تتسرب بيانات الاعتماد. rasdial يأخذها على سطر أوامره، حيث يمكن لمستخدمين محليين آخرين ولمعظم جامعي السجلات قراءتها:
subprocess.run(["rasdial", "Contoso L2TP"], check=True)فضّل بيانات اعتماد مقصورة على الحساب الذي يشغل المهمة، أو دع الملف الشخصي يخزنها باستخدام -RememberCredential، على تمرير كلمة مرور كوسيطة في مهمة مجدولة. أوامر التزويد نفسها آمنة للتكرار باستخدام -Force، لكنها ستغطي بسعادة مقترحاً قديماً، لذا فإن إعادة التشغيل تساعد فقط إذا كان السكربت يحمل القيم الحالية.
تستمر الملفات الشخصية عبر عمليات إعادة التشغيل وتعيش أطول من تكوين البوابة الذي بُنيت من أجله. عندما ينتقل مقترح البوابة، أزل الإدخال وأنشئه من جديد بدلاً من تكديس مجموعة قيم ثانية فوقه: Remove-VpnConnection -Name "Contoso L2TP" -Force، ثم كرر الأمرين بمجموعة القيم الجديدة.
أغلق الحلقة بأربعة فحوصات تعيش بجوار السكربت: Get-VpnConnection يعرض نوع النفق ومستوى التشفير المتوقعين؛ سجلات البوابة تُظهر طور 1 وطور 2 مكتملين لعنوان عميلك؛ rasdial يعيد النجاح ويفتح التطبيق؛ والمقترح المسجل في السكربت يطابق إعداد البوابة الحالي. عندما يصل 789 التالي، تستغرق تلك المقارنة دقائق بدلاً من فترة بعد الظهر.