SSTP และ IKEv2 ใช้การควบคุมใบรับรอง RRAS ที่แตกต่างกัน

หากคุณแทนที่ «ใบรับรอง 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 รวมถึงผลในการปรับใช้แบบกระจายโหลด ซึ่งเป็นส่วนที่ควรอ่านก่อนเปลี่ยนแปลงการผูก