منفذ في حقل عنوان VPN في Windows يعمل فقط مع SSTP

خادم VPN يستجيب على TCP 10443، ولدى عميل Windows المدمج بيانات الاعتماد الصحيحة، ومع ذلك تنقطع الاتصال بعد توقف يبدو وكأنه مهلة DNS. السبب عادة هو حقل العنوان: كتابة vpn.example.com:10443 في اسم الخادم أو العنوان تجعل Windows يقرأ السلسلة كلها كاسم مضيف، لأن ذلك الحقل ليس إدخال host:port عامًا. أما إمكان التعبير عن منفذ هناك فيعتمد على نوع النفق الذي يستخدمه الملف الشخصي، ونوع واحد فقط من الأنواع الأربعة يعامل القيمة كشيء يستطيع تحليله.

لماذا حقل العنوان ليس حقل host:port

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

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

الأنواع الثلاثة ذات المنفذ الثابت

يتصل PPTP بـ TCP 1723 ثم يحمل النفق في GRE، البروتوكول IP 47. ويستخدم L2TP/IPsec بروتوكول UDP 1701 للنفق وUDP 500 مع 4500 لـ IPsec، حيث 4500 هو منفذ عبور NAT. ويستخدم IKEv2 أيضًا UDP 500 و4500. لا يعرض أي من هذه الملفات حقل منفذ في أي مكان بالواجهة، ولن يتفاوض أي منها على منفذ غير قياسي.

لذلك يكون الخادم الذي يستمع على منفذ مخصص غير قابل للوصول من تلك الملفات، مهما كتب العنوان. الإجابات العملية ضيقة: انشر المنفذ القياسي على الخادم، أو ترجم المنفذ القياسي إلى المخصص على الموجّه الذي أمامه. كلاهما يترك ملف العميل دون مساس، وهو أمر بالغ القيمة عندما يُوزَّع الملف عبر سياسة لا بالكتابة اليدوية.

يحتاج SSTP إلى عنوان URL لا إلى اسم

SSTP هو الاستثناء لأنه يعمل داخل جلسة TLS. يجب أن يُحلَّل الحقل كعنوان URL: أولًا مخطط https://، ثم المضيف، ثم النقطتان والمنفذ. وبدون المخطط يواصل Windows معاملة القيمة كاسم عادي ويفشل الاتصال قبل حدوث أي تبادل TLS.

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

تُظهر ServerAddress بالضبط ما تم تخزينه. وإذا قُرئت كاسم مضيف مجرد يحتوي على نقطتين، فإن الملف لم يتلقَّ أي عنوان URL ولن يصلح أي عدد من المحاولات ذلك.

صيغة المورّد التي تُلصق في الحقل نفسه

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

تعامل مع المعامل الذي يعطّل التحقق من الشهادة كتحذير لا كإصلاح. فإذا كان الملف لا يتصل إلا بذلك المعامل، فالشهادة لا تطابق الاسم المستخدم، والإصلاح الصحيح يكون على البوابة لا في العميل. وrealm بعد المنفذ له الخاصية نفسها: لا يفعل شيئًا إلا إذا كان الخادم في الطرف الآخر يتوقعه.

أثبت المنفذ ثم اقرأ المرحلة الفاشلة

تأكد من أن شيئًا يقبل TCP على ذلك المنفذ من شبكة العميل قبل إلقاء اللوم على الملف:

Test-NetConnection vpn.example.com -Port 10443

النجاح يثبت وجود مستمع لا SSTP. فخادم ويب أو وكيل عكسي أو موازن حمل يمكنه إتمام مصافحة TCP ومع ذلك لا يتحدث SSTP، لذا فإن اختبارًا أخضر مع VPN أحمر مزيج حقيقي. قارن موضوع الشهادة بالاسم في الملف، وافحص سجل RasClient في الإصدارات التي تتضمنه، لأنه يسجل المرحلة التي فشلت بدلًا من مهلة عامة.

ثم فكّر في الخيار الذي يزيل المشكلة بدلًا من توثيقها: أعد توجيه TCP 443 من الخارج إلى 10443 على خادم VPN. عندئذ يستخدم العميل الملف الافتراضي دون أي منفذ، وهو عادة أنظف ترتيب لأسطول مُدار ويترك المنفذ المخصص تفصيلًا داخليًا.