خطأ PPTP 800 مقابل 812 وانقطاع الاتصال بعد دقيقة

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

الخطأ 800 يعني أن النفق لم ينشأ أبدا

يرفع Windows الخطأ 800 عندما لا يستطيع بناء النفق إطلاقا، والنص عن خادم لا يمكن الوصول إليه أو معايير أمان غير مناسبة هو ملخص وليس تشخيصا. يحتاج PPTP إلى شيئين منفصلين من الشبكة قبل فحص أي بيانات اعتماد. ينقل TCP 1723 قناة التحكم، وينقل بروتوكول IP رقم 47، أي GRE، الحمولة المغلفة.

اختبر ذلك المسار الخارجي من خارج شبكتك المحلية، لأن اتصالا يعمل داخل المكتب لا يثبت شيئا عن الحافة:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

إذا استجاب المنفذ 1723 وبقي الالتقاط فارغا بينما يحاول العميل الاتصال، فالمسار يسقط البروتوكول 47. راوتر يمرر 1723 لكن تمرير PPTP فيه معطل ينتج هذا النمط بالضبط: تكتمل مصافحة TCP ثم تختفي حزم GRE، فيبدو الفشل كمشكلة بيانات اعتماد رغم أنه لم تجرب أي عملية تسجيل دخول.

وجه التمرير إلى عنوان LAN الحالي للخادم، وفعل تمرير PPTP حيث يوفره الراوتر، وأعد المحاولة من نقطة المراقبة الخارجية نفسها. عندما يرشح GRE في المنبع ولا يمكنك تغيير ذلك، فإن SSTP عبر TCP 443 أو L2TP/IPsec عبر UDP 500 و4500 لديه فرصة أفضل من أي تغيير يمكنك إجراؤه على جانب Windows.

الخطأ 812 هو رفض الخادم لطريقة مصادقتك

يعود الخطأ 812 بعد أن يصبح النفق قائما، ولهذا يبدو كمشكلة كلمة مرور. الخادم يرفض طريقة المصادقة التي جرى التفاوض عليها للاتصال، وليس بالضرورة كلمة المرور نفسها. على العميل، افتح إدخال VPN، وانتقل إلى علامة التبويب الأمان، واضبط النوع على Point-to-Point Tunneling Protocol، واختر قائمة البروتوكولات الصريحة، وحدد Microsoft CHAP الإصدار 2.

يمكنك قراءة الإعداد الحالي دون النقر عبر مربع الحوار:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

الخادم الذي يشترط MS-CHAP v2 يرفض عميلا ترك على PAP أو على نوع تلقائي يتفاوض على شيء أضعف، ويصل الخطأ قبل تقييم أي كلمة مرور مستخدم. صيغة الحساب هي النصف الآخر من الرفض نفسه. في إحدى الحالات أرسل Windows هوية حساب Microsoft بالشكل MicrosoftAccount\[email protected] بينما أراد الخادم حسابا محليا أو حساب نطاق. كتابة SERVERNAME\username أخبرت Windows بمخزن الحسابات الذي يجب الرجوع إليه وأزالت الخطأ. أدخل الاسم يدويا بدلا من ترك بيانات اعتماد محفوظة تعيد إنتاج صيغة سابقة.

الانقطاعات بعد دقيقة هي قرار إبقاء حياة

عندما يتصل النفق ويمرر قليلا من حركة المرور ثم ينقطع، انظر إلى سلوك صدى LCP على الخادم قبل أن تلمس العميل. يسأل البرنامج الخفي النظير دوريا أن يؤكد أنه لا يزال موجودا. إذا وصلت ردود قليلة جدا داخل الميزانية المعدة، تنهى الجلسة رغم أن المستخدم لا يزال لديه وصلة عاملة.

على خادم Linux من نوع pptpd تعيش تلك القيم في /etc/ppp/options.pptpd، والإصلاح المعتاد هو توسيع الميزانية بدلا من تقصير الفاصل:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

ثلاثون فوات بفاصل خمس ثوان تغفر تعثرا قصيرا بدلا من إعلان أن النظير اختفى. تقليص العدد إلى واحد أو اثنين يحول الاهتزاز العادي على مسار مترجم إلى انقطاع كل دقيقة تقريبا. إذا كان خادمك Windows RRAS بدلا من pptpd، فانظر بدلا من ذلك إلى مهلة جلسة PPP وسياسة قطع الاتصال عند الخمول. تلك تعيش في مكان آخر، وتحرير ملف pppd غير موجود لن يغير شيئا.

الشبكات الفرعية المتداخلة تكسر مسار البيانات

يمكن لنفق PPTP أن يصادق بنظافة ومع ذلك لا يصل إلى شيء عندما يستخدم الموقعان النطاق الخاص نفسه، مثلا 192.168.1.0/24 في المكتب وفي المنزل. لا يستطيع العميل معرفة أي مضيف يقصده عنوان معين، وترفض بعض حزم البروتوكول تثبيت المسار كليا بدلا من اختيار واحد.

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

ابدأ بالمرحلة التي فشلت: GRE من أجل 800، والطريقة وسلسلة الحساب من أجل 812، وإعدادات الصدى لنفق يموت وفق جدول.