قيمة سجل NAT-T في Windows: افحص الطوبولوجيا أولاً
يجيب AssumeUDPEncapsulationContextOnSendRule عن سؤال واحد يخص موضع NAT في L2TP/IPsec، وهو ليس إصلاحاً عاماً لخطأ VPN في Windows.
يفشل اتصال VPN في Windows، ويعيد البحث قيمة سجل، وتُدخل القيمة مع إعادة تشغيل. تنجح تلك التسلسلة أحياناً ولا تفسر شيئاً أبداً. الإعداد المعني يجيب عن سؤال واحد حول موضع الخادم بالنسبة لجهاز NAT، ولا معنى له حتى تعرف أي بروتوكول فشل وفي أي مرحلة.
ما الذي تختاره القيمة فعلاً
يحكم AssumeUDPEncapsulationContextOnSendRule ما إذا كان تنفيذ IPsec في Windows سيحاول إنشاء ارتباطات مع طرف خلف جهاز NAT. القيمة الافتراضية الموثقة 0 لا تسمح بتلك الحالة، و1 يسمح بها عندما يكون الخادم هو الجانب الواقع خلف NAT، و2 يغطي ترجمة الطرفين. هذه عبارات طوبولوجية عن مَن في أين.
إذا قرأتها كسلسلة، فإن الأرقام تصف ترجمة متزايدة وليست موثوقية متزايدة. تعيين 2 على شبكة لا تُترجم فيها أي عناوين لا يجعل الاتصال أسرع ولا أثبت، ولا يصلح فشل مصادقة. إرشادات Microsoft بشأن NAT في L2TP/IPsec توثّق السياسة وسياقها التاريخي للمنصات. تحقق من ذلك السياق مقابل إصدار Windows والدور الذي تشغله فعلاً، لأن مستنداً صمد عبر عدة إصدارات ليس بياناً عن كل إصدار حالي.
طابق الطوبولوجيا قبل الرقم
ارسم المسار وحدد نقاط الترجمة: هل العميل خلف راوتر منزلي، وهل الخادم خلف موازن تحميل أو جدار ناري يعيد كتابة العناوين، وهل يقع أي طرف خلف ترجمة يقدمها المشغل ولا تتحكم فيها. بعد ذلك الرسم فقط يمكنك أن تقرر ما إذا كانت القيمة تنطبق، وعلى أي طرف.
الادعاء بأن إصدارات Windows Server الحالية تُشحن ببساطة وعبور NAT معطّل فيها أوسع من أن يُبنى عليه. المهم هو السياسة على نظامك، والطوبولوجيا أمامه، والتبادل الذي فشل، وبهذا الترتيب. إذا كان الطرفان لهما عناوين عامة، فالإعداد ليس مشكلتك. انظر إلى العرض أو الشهادة أو الحساب بدلاً من ذلك، واترك السجل كما هو.
افحص مرحلة الفشل أولاً
L2TP/IPsec ينتج ثلاث حالات فشل مختلفة على الأقل: تعذر الوصول إلى الطرف الآخر، وتعذر إنشاء حماية IPsec، و رفض مصادقة مستخدم PPP بعد وجود النفق. لا يمكن إصلاح حساب مرفوض بتغيير سياسة NAT، ولا يمكن إصلاح عدم تطابق العرض بإعادة التشغيل.
Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfacesالمهلة بلا مستجيب تشير إلى الوصول أو التصفية لا إلى السياسة. الرفض السريع مع رسالة عرض يشير إلى الخوارزميات. الفشل بعد قيام النفق ينتمي إلى مرحلة المصادقة، وهي مالك آخر وإصلاح آخر.
لـ SSTP عبر HTTPS و IKEv2 الأصلي سجلاتهما وضوابطهما الخاصة. لا شيء فيهما يصبح حالة عبور NAT لمجرد أنهما يعملان على Windows أيضاً.
نفّذ التغيير مع طريق للعودة
إذا استدعت السياسة الموثقة والطوبولوجيا الملاحظة ذلك معاً، فسجّل القيمة السابقة، وطبّق التغيير عبر الإعداد المُدار لا عبر نص برمجي لكل ملف تعريف، وخطط لإعادة التشغيل. على خادم يدعم أحمال عمل أخرى، هذه ليست تعديلاً غير ضار.
لا يزال على جهاز NAT حمل النقل المُغلّف وحركة العودة. قيمة السجل لا تنشئ قاعدة توجيه ولا توائم العروض ولا تتحقق من أي هوية، لذا فالاتصال الذي يبدأ بالعمل بعد التغيير قد يعمل لسبب مختلف تماماً. أعد اختبار البروتوكول الأصلي بالطوبولوجيا الأصلية، ثم اكتب أي مرحلة فشلت ولماذا كان يُتوقع أن تعالجها القيمة. تلك الجملة هي ما يحول شائعة إنترنت إلى إعداد يمكن الدفاع عنه.