สร้าง VPN แบบ IKEv2 ใน PowerShell ด้วยใบรับรองเครื่อง

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

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

ใบรับรองก่อน อุโมงค์ทีหลัง

การนำเข้าสองอย่างมีความสำคัญ ตัวตนของไคลเอนต์ไปที่ Cert:\LocalMachine\My ผ่าน Import-PfxCertificate และ CA ที่ออกใบรับรองไปที่ Cert:\LocalMachine\Root ผ่าน Import-Certificate ใบรับรองปลายทางเพียงใบเดียวไม่พิสูจน์ห่วงโซ่ใด ๆ การข้ามการนำเข้าครั้งที่สองจึงทำให้การตรวจสอบไม่มีฐานรองรับ นอกจากความมีอยู่แล้ว คีย์ส่วนตัวต้องถูกแนบไว้และบัญชีคอมพิวเตอร์ต้องได้รับอนุญาตให้อ่าน Get-ChildItem Cert:\LocalMachine\My แสดงรายการสิ่งที่มาถึง เปรียบเทียบลายนิ้วมือแทนที่จะเทียบชื่อเรื่อง เพราะชื่อเรื่องที่เกือบเหมือนกันเป็นเรื่องปกติ

ตรวจสอบการใช้งานคีย์แบบขยายก่อนนำไปใช้ การพิสูจน์ตัวตนไคลเอนต์เป็นข้อกำหนดปกติสำหรับตัวตนเครื่อง IKEv2 และอีกฝั่งต้องไว้วางใจ CA ที่ลงนามในใบรับรองนั้น ตัวตนในที่เก็บของผู้ใช้ไม่มีอยู่สำหรับการเชื่อมต่อในบริบทของคอมพิวเตอร์

สร้างโปรไฟล์และเส้นทางของมัน

Add-VpnConnection -Name "Office IKEv2" -ServerAddress vpn.example.com -TunnelType Ikev2 -EncryptionLevel Required -AuthenticationMethod MachineCertificate -AllUserConnection เขียนโปรไฟล์ สวิตช์ -AllUserConnection เผยแพร่โปรไฟล์นั้นในสมุดโทรศัพท์ส่วนกลาง เหมาะกับเครื่องที่ใช้ร่วมกันหรือเครื่องที่จัดการโดยบริการ ละไว้สำหรับผู้ใช้คนเดียว ที่อยู่ใดก็ตามที่ส่งไปต้อง ตรงกับชื่อ DNS ในใบรับรองของเซิร์ฟเวอร์ไม่เช่นนั้นความล้มเหลวจะปรากฏหลังอุโมงค์ขึ้นแล้ว จากนั้นเพิ่มคำนำหน้าเส้นทางทีละรายการด้วย Add-VpnConnectionRoute และเฉพาะรายการที่การออกแบบต้องการจริง ๆ

IPv6 มีความแปลกอย่างหนึ่ง Windows ไม่ยอมรับ ::/0 เป็นเส้นทาง VPN ดังนั้น ::/1 และ 8000::/1 จึงครอบคลุมพื้นที่ที่อยู่เดียวกันเมื่อใช้ร่วมกัน การกำหนดเส้นทางคำนำหน้าก็ไม่ได้ให้สิทธิ์ใด ๆ ที่ไฟร์วอลล์ปลายทาง รายการคำนำหน้าและนโยบายไฟร์วอลล์จึงยังเป็นเอกสารแยกกัน

ข้อมูลรับรองเป็นของวิธีการพิสูจน์ตัวตน

โปรไฟล์ใบรับรองเครื่องไม่ต้องใช้ความลับของผู้ใช้เลย ในขณะที่โปรไฟล์ EAP-MSCHAPv2 ต้องใช้ ในกรณีหลังโมดูล VPNCredentialsHelper ให้ Set-VpnConnectionUsernamePassword และต้องการข้อความธรรมดา $cred.Password เป็น SecureString จึงต้องแกะออกก่อนด้วย GetNetworkCredential().Password ติดตั้งโมดูลทุกที่ที่คำสั่งทำงาน ไม่ใช่เฉพาะเวิร์กสเตชันที่เขียนคำสั่ง EAP-TLS หรือวิธีที่กำหนดเองไม่ใช้ cmdlet นี้เลย แต่รับ XML การกำหนดค่า EAP แทน

rasdial "Office IKEv2" ยกการเชื่อมต่อจากเชลล์ ซึ่งเป็นวิธีที่เร็วที่สุดในการเห็นผลลัพธ์ที่เบื้องหน้าแทนที่จะเป็นบันทึกเหตุการณ์

สิ่งที่อุโมงค์ที่เชื่อมต่อแล้วไม่ได้พิสูจน์

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

เมื่อเปลี่ยนโปรไฟล์ ให้ลบโปรไฟล์เดิมด้วย Remove-VpnConnection -Name "Office IKEv2" -Force ก่อนสร้างใหม่ มิฉะนั้นการตั้งค่าและเส้นทางเก่าจะคงอยู่หลังการแก้ไข หากยังเชื่อมต่อไม่ได้ ให้เปรียบเทียบลายนิ้วมือที่บันทึกไว้ในโปรไฟล์กับลายนิ้วมือที่มีอยู่ในที่เก็บ เพราะ Windows อาจอ้างอิงถึงตัวตนที่ถูกแทนที่ไปแล้วภายใต้ชื่อเรื่องที่ไม่เปลี่ยนแปลง

เก็บลายนิ้วมือ วิธี EAP และรายการเส้นทางไว้ข้างโปรไฟล์ เมื่อรวมกันแล้วสิ่งเหล่านี้ธิบายปัญหาส่วนใหญ่ที่เกิดขึ้นภายหลัง