تمرير PPTP مفقود: إصلاح خطأ 807 في Windows VPN

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

جدول المنافذ ليس فيه صف لرقم بروتوكول

يستخدم PPTP محادثتين تفشلان بطرق مختلفة. المحادثة على TCP 1723 تبدأ الاتصال وتمرر معلومات الارتباط وتنهيه عندما ينقطع المستخدم. أما جانب الحمولة فيعمل داخل GRE، الذي توسمه ترويسة IP برقم البروتوكول 47، وداخل ذلك النفق يتفاوض PPP على الارتباط بينما يتحقق MS-CHAPv2 من بيانات الاعتماد.

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

ما يبلغ عنه Windows عندما يموت مسار البيانات

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

اعمل على النقل قبل أن تلمس كلمة المرور. تغيير بيانات الاعتماد لمطاردة الخطأ 807 يترك العطل الحقيقي في مكانه ويجعل المحاولة التالية أصعب قراءة.

لماذا يكسر عميل ثانٍ نفقًا عاملًا

بما أنه لا توجد منافذ تميز بينهما، لا يستطيع جهاز NAT فصل عميلَي PPTP كما يفصل جلستي HTTPS. لذلك تسمح كثير من أجهزة المستهلكين باتصال PPTP واحد وتتابعه عبر عنوان المصدر. الحاسوب المحمول الذي عمل وحده يتوقف عن الإكمال بمجرد أن يتصل جهاز ثانٍ، ومن جهة العميل يبدو الفشل عشوائيًا. هذا النمط يخص البرنامج الثابت، ولن يغيره أي تعديل في الملف الشخصي.

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

أثبت أي نصف يفشل

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

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

المكافئ في Wireshark هو مرشح العرض ip proto 47، وهو أسهل لتسليمه إلى شخص لا يرتاح في سطر الأوامر. ووصول GRE دون خروج أي شيء في الرد يعني أن مسار العودة يحتاج إلى إصلاح.

ما يصلح الخطأ فعلًا

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

استبدال PPTP هو الخيار الآخر وغالبًا الأرخص. فالموجه الذي ينهي VPN بنفسه يتجنب ازدواج NAT للعملاء القادمين، والبروتوكول الذي يتعامل معه NAT القائم على المنافذ أصلًا لا يحتاج إلى أي تمرير: OpenVPN عبر UDP، أو SSTP عبر TCP 443، أو L2TP/IPsec مع NAT-T الذي يلف ESP في UDP 4500. كما يعتمد PPTP على MS-CHAPv2، ونقاط ضعفه الموثقة تجعله خيارًا سيئًا لنشر جديد حتى بعد زوال الخطأ.

دوّن أي قاعدة أحدثت الفرق، لأن الموقع نفسه سيلقى الحد نفسه عندما يطلب المستخدم الثاني الوصول. والإصلاح على مستوى البروتوكول مكانه ملاحظات الشبكة، حيث سينظر المهندس التالي.