يستخدم SSTP وIKEv2 عناصر تحكم مختلفة لشهادات RRAS
يربط SslCertificate مستمع SSTP؛ وتنتمي CertificateAdvertised إلى IKEv2 الوارد. سمِّ البروتوكول، وافحص الشهادة الطرفية، ثم غيّر ارتباطًا واحدًا.
إذا استبدلت «شهادة VPN»، فقد تغيّر الخدمة الخطأ. يحتفظ RRAS بثلاثة عناصر تحكم على الأقل في الشهادات، وينتمي كل منها إلى بروتوكول مختلف ودور اتصال مختلف. تسمية البروتوكول أولاً تحوّل تخمينًا محفوفًا بالمخاطر إلى تغيير واحد قابل للتراجع في الارتباط. كل ما يلي يعتمد على تلك الجملة الواحدة.
سمِّ البروتوكول قبل الشهادة
يعرض مستمع SSTP شهادة TLS لعميل يتصرف مثل HTTPS. ويعلن اتصال IKEv2 الوارد من موقع إلى موقع هوية خادم ويتحقق من شهادات الأقران مقابل جذر موثوق. ويحمل تعريف من موقع إلى موقع لكل واجهة هوية جهاز خاصة به.
هذه ثلاثة عناصر تحكم بثلاثة نطاقات. إن الخلط بينها ينتج تغييرًا يبدو ناجحًا على أحد البروتوكولين ولا أثر له على الآخر، وهو أسوأ من فشل واضح. سجّل أي بروتوكول فشل، وأي جانب قدّم الشهادة، وأي جانب رفضها قبل أن تلمس أي شيء.
SSTP ارتباط HTTPS
في عمليات نشر Remote Access المدعومة، يكشف Set-RemoteAccess عن المعامل SslCertificate المستخدم لاتصال SSTP ولدور DirectAccess المرتبط بـ HTTPS.
يتبع نطاق التحقق والنشر الخاص به تكوين Remote Access، لذا قد يصل تغيير ارتباط واحد إلى أكثر من اتصال أو عقدة. في نشر موزّع الحمل يشمل هذا النطاق كل عقدة يغطيها التكوين. إن تغيير عقدة واحدة واختبار عميل واحد يترك الباقي يعرض الشهادة الطرفية القديمة، وهو بالتحديد ذلك التغيير النصفي الذي ينجو من نافذة صيانة.
تحقق من اسم الخدمة المتوقع والسلسلة والصلاحية والاستخدام المقصود وتوافر المفتاح الخاص قبل التحديث. يجب أن تطابق الشهادة الاسم الذي سيتحقق منه العميل، واسم المحوّل ليس ذلك الاسم.
لـ IKEv2 الوارد معامله الخاص
يضبط Set-VpnAuthProtocol مصادقة IKEv2 الواردة من موقع إلى موقع، ويوفّر CertificateAdvertised شهادة عندما يستخدمها وضع مصادقة النفق. وهو ليس أمرًا عامًا لاختيار أي شهادة خادم على المضيف.
أبقِ كائنين منفصلين: الشهادة الطرفية التي يعرضها الخادم كهويته، والجذر الذي يستخدمه لقبول شهادات الأقران. إن اختيار الجهة المصدّرة التي تثق بها لا يقول شيئًا عن الشهادة الطرفية التي يعرضها الخادم.
تُضبط هوية واجهة من موقع إلى موقع منفردة عبر Set-VpnS2SInterface. وهي ليست شهادة SSTP تلقائيًا، حتى عندما يقع كلاهما في المخزن نفسه على الجهاز نفسه.
افحص المرشح أولاً
يعرض عرض مركّز لمخزن الجهاز المحلي بيانات وصفية عامة دون تصدير أي شيء خاص:
Get-ChildItem Cert:\LocalMachine\My |
Select-Object Thumbprint, Subject, HasPrivateKey, NotAfterتلك القائمة نقطة انطلاق وليست اختبار ملاءمة. افحص إدخالات SAN واستخدامات المفتاح الموسّعة والسلسلة ووصول حساب الخدمة إلى المفتاح الخاص للبروتوكول الذي تكوّنه.
الشهادة المثبّتة لهوية عميل سحابي غير ذات صلة ليست مناسبة لمجرد ظهورها في المخزن نفسه. الرؤية ليست أهلية، وبصمة في لقطة شاشة لا تثبت شيئًا عن قدرة حساب الخدمة على قراءة المفتاح. تحقق من ذلك الوصول صراحةً، لأن إذن المفتاح المفقود لا يُظهر فشله إلا عند إعادة تشغيل الخدمة ومحاولتها استخدام الشهادة.
سجّل الارتباط الحالي وتأكد من أنك ما زلت تستطيع الوصول إلى المضيف بطريقة أخرى قبل تغييره. مسار الاسترداد جزء من التغيير، وليس من الحادث الذي يليه.
التجديد ليس تنشيطًا
إن إعادة إصدار شهادة إجراء مختلف عن اختيارها للخدمة العاملة. قد تحتفظ الشهادة الطرفية الجديدة بهوية DNS المقصودة وتحمل في الوقت نفسه بصمة مختلفة، فلا شيء يشير إليها حتى يُحدَّث الارتباط. التجديد يغيّر الكائن؛ والتنشيط يغيّر الإشارة إليه. إن الخلط بينهما هو سبب بقاء شهادة مجددة بشكل صحيح دون استخدام لأسابيع.
طبّق التغيير المدعوم في نافذة مناسبة، بما في ذلك أي إعادة تشغيل موثقة، ثم افحص الشهادة من اتصال جديد بالبروتوكول المقصود. قد تعرض جلسة عميل مخزّنة مؤقتًا الشهادة الطرفية القديمة وتجعل التغيير الصحيح يبدو معطوبًا.
اسحب الشهادة السابقة عبر العملية المعتادة فقط بعد نجاح ذلك الفحص. توثّق مرجع Set-RemoteAccess نطاق معامل SSL، بما في ذلك أثره في عمليات النشر الموزّعة الحمل، وهو الجزء الجدير بالقراءة قبل تغيير الارتباط.