ทำไม Windows IKEv2 แบบเนทีฟจึงไม่มีฟิลด์ PSK เลย

เอกสารของเกตเวย์บอกให้ใส่คีย์ที่แชร์ไว้ล่วงหน้าในไคลเอนต์ แต่โปรไฟล์ Windows ไม่มีฟิลด์สำหรับมัน ช่องว่างนี้ไม่ใช่บั๊กที่หลบเลี่ยงได้ด้วยการพิมพ์คีย์ลงในช่องรหัสผ่าน มันคือความแตกต่างระหว่างสิ่งที่โปรโตคอลทำได้กับการนำไปใช้เฉพาะรายที่เสนออะไรบางอย่าง

ความสามารถของโปรโตคอลไม่ใช่การสนับสนุนของไคลเอนต์

ข้อกำหนดของ IKEv2 รวมถึงการพิสูจน์ตัวตนด้วยคีย์ที่แชร์กัน เกตเวย์จึงกำหนดค่าให้ใช้ได้อย่างชอบธรรม โปรไฟล์การเข้าถึงระยะไกลแบบเนทีฟของ Windows กลับบันทึกการจัดวางด้วยใบรับรองและ EAP และความสามารถของโปรโตคอลไม่ได้สร้างฟิลด์ พารามิเตอร์ หรือค่ารีจิสทรีที่ไคลเอนต์ไม่เคยมี

โดยปกติผู้คนไปจบที่ เอกสารอ้างอิง PowerShell สำหรับการเพิ่มการเชื่อมต่อ VPN ซึ่งแสดง L2tpPsk สำหรับการจัดวาง L2TP พารามิเตอร์นั้นเป็นของ L2TP ไม่ใช่ความลับทั่วไปของ IKEv2 การตั้งค่าการเลือกอัลกอริทึมเลือกพารามิเตอร์ป้องกัน ซึ่งเป็นเรื่องที่สามที่ไม่เกี่ยวข้อง บทบาทการกำหนดเส้นทางของ Windows Server ก็ไม่ใช่วัตถุเดียวกัน อินเทอร์เฟซของเซิร์ฟเวอร์อาจมีตัวควบคุมการกำหนดค่าที่โปรไฟล์ไคลเอนต์เดสก์ท็อปไม่มี และการคัดลอกการตั้งค่าเซิร์ฟเวอร์ไปยังโปรไฟล์เวิร์กสเตชันไม่ได้จำลองความสามารถนั้น

เลือกระหว่างใบรับรอง EAP หรือ L2TP

ถ้าผู้ดูแลเกตเวย์ยอมรับการพิสูจน์ตัวตนด้วยใบรับรอง นั่นมักเป็นปลายทางที่สะอาดที่สุด: ไคลเอนต์แสดงใบรับรอง เกตเวย์ตรวจสอบกับผู้ออกที่เชื่อถือได้ และไม่มีความลับที่แชร์กันเหลืออยู่ในโปรไฟล์ให้ใครคัดลอก ต้องมีการลงทะเบียน ห่วงโซ่ที่เชื่อถือได้ และการกำหนดค่าเกตเวย์ที่เชื่อมใบรับรองกับการตัดสินใจอนุญาต

EAP ที่ใช้ข้อมูลรับรองของผู้ใช้เป็นอีกเส้นทางที่รองรับบนไคลเอนต์นี้ และย้ายการตัดสินใจไปยังผู้ให้บริการตัวตน มันนำข้อพึ่งพาของตัวเองมาด้วย เพราะวิธีการ EAP ใบรับรองเซิร์ฟเวอร์ และความไว้วางใจของไคลเอนต์ในใบรับรองนั้นต้องสอดคล้องกันทั้งหมด การเปลี่ยนไปใช้ L2TP/IPsec เพียงเพื่อให้ได้ฟิลด์ที่คุ้นเคยเปลี่ยนสแต็กโปรโตคอล นั่นยอมรับได้เมื่อเป็นการเลือกที่รองรับและมีเหตุผลบันทึกไว้ และเป็นผลลัพธ์ที่ไม่ดีเมื่อเกิดขึ้นเพราะมีคนกำลังมองหากล่องสำหรับพิมพ์คีย์

ตรวจสอบว่าเกตเวย์จะยอมรับอะไร

ถามผู้ดูแลว่าบริการเข้าถึงระยะไกลเสนอวิธีการพิสูจน์ตัวตนใดในปัจจุบัน ไม่ใช่ผลิตภัณฑ์รองรับสิ่งใดโดยทั่วไป บริการที่กำหนดค่าสำหรับ IKEv2 ด้วย PSK เท่านั้นจะไม่ยอมรับใบรับรองเพียงเพราะไคลเอนต์ชอบมัน

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

อ่านวิธีการพิสูจน์ตัวตนของโปรไฟล์และที่เก็บใบรับรองไปพร้อมกัน โปรไฟล์ที่ตั้งเป็น EAP โดยไม่มีใบรับรองที่ใช้ได้อยู่ข้างหลังจะล้มเหลวในลักษณะที่ดูเหมือนปัญหาเซิร์ฟเวอร์

ถ้าคำตอบคือมีเพียง PSK ตัวเลือกที่ซื่อสัตย์คือไคลเอนต์ที่ได้รับอนุมัติซึ่งรองรับมัน หรือการเปลี่ยนแปลงการออกแบบการพิสูจน์ตัวตนของเกตเวย์ ทั้งสองไม่ใช่ทางแก้เฉพาะเครื่อง และการแกล้งทำเป็นอย่างอื่นจะให้การเชื่อมต่อที่เฉพาะคนที่กำหนดค่าไว้เท่านั้นจึงจะทำซ้ำได้

บันทึกการตัดสินใจและความลับ

จดวิธีการที่เลือก จุดยึดความเชื่อถือ ตัวตนที่จับคู่กับมัน และผู้ที่อนุมัติการเปลี่ยนแปลง บันทึกนั้นคือสิ่งที่การทบทวนเหตุการณ์ต้องใช้ และยังเป็นสิ่งที่กันวิศวกรคนถัดไปไม่ให้ค้นพบทางตันเดิมอีกครั้ง

แยกความลับในบันทึกของคุณ: รหัสผ่านบัญชี วลีรหัสผ่านของคีย์ส่วนตัว และคีย์ที่แชร์ไว้ล่วงหน้าของเกตเวย์เป็นสามสิ่งที่แตกต่างกัน แม้หน้าจอการตั้งค่าจะเรียกทั้งหมดว่ารหัสผ่าน การสับสนระหว่างกันคือวิธีที่คีย์ไปจบในตั๋ว ทดสอบโปรไฟล์ที่ได้ด้วยการเชื่อมต่อใหม่และคำขอแอปพลิเคชันหนึ่งครั้งไปยังทรัพยากรส่วนตัว อุโมงค์ที่สำเร็จโดยไม่มีบริการที่เข้าถึงได้เป็นผลลัพธ์บางส่วน และไม่ควรอธิบายโปรไฟล์ว่าสมบูรณ์จนกว่าทรัพยากรจะทำงานด้วย