นำเข้าโปรไฟล์ VPN ใน PowerShell ด้วย Add-VpnConnection

Add-VpnConnection สร้างเฉพาะโปรไฟล์ Windows แบบเนทีฟ จับคู่ทันเนลและวิธียืนยันตัวตนให้ตรงกับเกตเวย์ กำหนดขอบเขตอย่างตั้งใจ แล้วทดสอบเส้นทางและ DNS

ไม่มี cmdlet ชื่อ Import-VpnProfile และตัวที่ใกล้เคียงที่สุดอย่าง Add-VpnConnection ไม่เคยอ่านไฟล์ .ovpn หรือ .conf มันประกอบโปรไฟล์ Windows แบบเนทีฟจากพารามิเตอร์ที่คุณส่งเข้าไป ดังนั้นจุดตรวจแรกตรงนี้คือรูปแบบไฟล์ ไม่ใช่บรรทัดคำสั่ง ถ้าเกตเวย์รองรับ SSTP IKEv2 L2TP/IPsec หรือ PPTP Windows ก็เป็นเจ้าของโปรไฟล์ได้ และรายการที่เหลือยังใช้ได้ ถ้าคุณได้ไฟล์ OpenVPN หรือ WireGuard มา ให้หยุดที่ขั้นตอนแรก เพราะไคลเอนต์เหล่านั้นมีตัวนำเข้าของตัวเอง

ขั้นตอนที่ 1: ยืนยันโปรไฟล์ที่ Windows เป็นเจ้าของได้จริง

ก่อนอื่นให้รัน Get-Command -Module VpnClient บนเครื่องนี้ Windows 10, Windows 11 และ Server 2016 หรือใหม่กว่ามีโมดูลนี้มาด้วย ถ้าไม่มี ไม่มีสคริปต์ที่คัดลอกมาจะทำให้โฮสต์นี้ยอมรับโปรไฟล์แบบเนทีฟได้ cmdlet ที่สำคัญคือ Add-VpnConnection, Get-VpnConnection และ Remove-VpnConnection และรายการพารามิเตอร์ใน เอกสารอ้างอิง Add-VpnConnection คุ้มค่าที่จะอ่านให้ครบสักครั้ง

แบบเนทีฟหมายความว่าสแตก VPN ของ Windows เป็นตัวปิดทันเนล ซึ่งครอบคลุม IKEv2 ซึ่งมักใช้ใบรับรองเครื่อง SSTP ที่เป็นการยืนยันตัวตนผู้ใช้หรือใบรับรองอยู่ข้างใน และ L2TP/IPsec ที่ใช้คีย์ที่แชร์ล่วงหน้า ไฟล์ .ovpn คือสคริปต์ OpenVPN ไม่ใช่การเชื่อมต่อของ Windows เพราะมีคำสั่งอย่าง remote, cipher หรือ tls-auth ที่สแตก Windows ไม่รู้จักเลย ไฟล์ .conf ของ WireGuard ก็เรื่องเดียวกันกับ PrivateKey และ AllowedIPs การแปลงสิ่งหนึ่งเป็นอีกสิ่งหนึ่งไม่ใช่การเลือกพารามิเตอร์ แต่เป็นการใช้งานทันเนลคนละแบบ

มีทางที่สาม ถ้าผู้ดูแลระบบส่งเอกสาร XML ของ VPNv2 CSP หรือโปรไฟล์ Intune มาให้ นั่นคือเส้นทาง MDM ซึ่งสแตกการจัดเตรียมเป็นตัวใช้ ไม่ใช่ Add-VpnConnection อย่าแปลชื่อโหนดเหล่านั้นเป็นพารามิเตอร์ของ PowerShell ให้ถามแทนว่ากลไกใดเป็นตัวใช้ XML

ขั้นตอนที่ 2: จับคู่ประเภททันเนลกับวิธียืนยันตัวตน

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

  • IKEv2 กับ MachineCertificate: ไคลเอนต์แสดงใบรับรองของคอมพิวเตอร์ และตั้ง -EncryptionLevel Required ด้วย
  • SSTP กับ Eap: ทันเนล TLS ก่อน แล้วจึงเป็น PEAP/MSCHAPv2 หรือใบรับรองภายใน EAP ซึ่งต้องใช้ XML ในขั้นตอนที่ 3
  • SSTP, L2TP หรือ PPTP กับ MSChapv2, Chap หรือ Pap: ชื่อผู้ใช้และรหัสผ่านธรรมดา ไม่มี EAP blob
  • L2TP กับ MSChapv2 และ -Lt2pPsk: PSK ครอบคลุมครึ่ง IPsec ส่วนผู้ใช้ครอบคลุม PPP ทั้งสองต้องตรงกับเซิร์ฟเวอร์

splat เก็บค่าไว้ที่เดียว:

$p = @{
  Name                 = "Corp IKEv2"
  ServerAddress        = "vpn.example.com"
  TunnelType           = "Ikev2"
  AuthenticationMethod = "MachineCertificate"
  EncryptionLevel      = "Required"
  SplitTunneling       = $false
  DnsSuffix            = "corp.example.com"
}
Add-VpnConnection @p -PassThru

-PassThru คืนออบเจ็กต์ที่ Windows เพิ่งเขียน ดังนั้นคุณจึงตรวจดูได้โดยไม่ต้องเรียกครั้งที่สอง ถ้าชื่อมีอยู่แล้ว cmdlet จะปฏิเสธไม่ยอมทำงาน ส่วน -Force จะเขียนทับ ซึ่งเป็นปฏิกิริยาที่ผิดบนแล็ปท็อปใช้งานจริง เพราะมันทิ้งสิ่งที่คนอื่นตั้งค่าไว้ด้วยมืออย่างเงียบ ๆ

ขั้นตอนที่ 3: ส่งมอบวัสดุรับรองตัวตนอย่างถูกต้อง

รหัสผ่าน คีย์ที่แชร์ล่วงหน้า และ EAP blob คือจุดที่สคริปต์เหล่านี้มักพัง -EapConfigXmlStream ต้องการ XmlDocument ไม่ใช่พาธ ดังนั้นให้อ่านไฟล์และแปลงชนิดก่อน การส่งสตริงทำให้เกิดข้อผิดพลาดในการแปลงที่อ่านดูเหมือนปัญหา schema และทำให้คนไปเขียน XML ที่ไม่เคยผิดใหม่

$eap = [xml](Get-Content -Raw .\peap-mschapv2.xml)
Add-VpnConnection -Name "Corp SSTP" -ServerAddress "sstp.example.com" `
  -TunnelType Sstp -AuthenticationMethod Eap `
  -EapConfigXmlStream $eap -EncryptionLevel Required

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

สำหรับ IKEv2 ครึ่งที่เป็นใบรับรองคือการค้นหาในที่เก็บ -MachineCertificateIssuerFilter รับออบเจ็กต์ใบรับรอง และ Windows ใช้มันหาใบรับรองไคลเอนต์ที่ใช้ได้ใน LocalMachine\My ใบรับรองต้องมีคีย์ส่วนตัวและห่วงโซ่ที่เซิร์ฟเวอร์ไว้ใจ ถ้าขาดอย่างใดอย่างหนึ่ง การยืนยันตัวตนจะล้มเหลวโดยไม่มีรายละเอียดที่เป็นประโยชน์ ดังนั้นตรวจที่เก็บก่อน:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) } |
  Select-Object Subject, Issuer, Thumbprint, NotAfter

เก็บความลับไว้นอกไฟล์สคริปต์ PSK ที่ส่งบนบรรทัดคำสั่งหรือฝังใน .ps1 จะไปอยู่ในบันทึก เซสชันที่บันทึกไว้ และที่เก็บโค้ดที่แชร์ และ -RememberCredential แคชข้อมูลรับรองผู้ใช้ไว้ใช้ภายหลัง เปลี่ยนการทดสอบครั้งเดียวให้กลายเป็นการอนุญาตถาวร

ขั้นตอนที่ 4: ตัดสินขอบเขตก่อนรันครั้งแรก

cmdlet เดียวกันเขียนลงสมุดโทรศัพท์สองเล่มที่ต่างกัน ถ้าไม่ใส่ -AllUserConnection โปรไฟล์เป็นของคุณและอยู่ใต้ %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk ถ้าใส่ จากพรอมต์ที่ยกระดับสิทธิ์ ทุกบัญชีจะเห็นโปรไฟล์ รวมถึงหน้าจอลงชื่อเข้าใช้ และมันไปอยู่ที่ %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk

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

# elevated prompt
Remove-VpnConnection -Name "Corp IKEv2" -Force
Add-VpnConnection -Name "Corp IKEv2" -ServerAddress "vpn.example.com" `
  -TunnelType Ikev2 -AuthenticationMethod MachineCertificate `
  -EncryptionLevel Required -AllUserConnection

ขั้นตอนที่ 5: ทดสอบว่าทันเนลต้องส่งมอบอะไรจริง ๆ

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

rasdial "Corp IKEv2"
Get-VpnConnection -Name "Corp IKEv2" |
  Select-Object Name, ServerAddress, TunnelType, ConnectionStatus, SplitTunneling
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

สองความล้มเหลวที่ผู้ใช้รายงานขณะที่สถานะยังบอกว่าเชื่อมต่อแล้วคือ DNS และการกำหนดเส้นทาง แปลงชื่อภายในและดูว่าเซิร์ฟเวอร์ใดตอบ โปรไฟล์ที่ไม่มี -DnsSuffix อาจสร้างทันเนลได้สมบูรณ์แบบแต่ยังล้มเหลวทุกการค้นหาในอินทราเน็ต จากนั้น ดูเส้นทางเริ่มต้น: เมื่อปิด split tunneling เส้นทาง 0.0.0.0/0 ที่มีเมตริกต่ำสุดควรชี้เข้าอินเทอร์เฟซ VPN และเมื่อเปิด เฉพาะคำนำหน้าที่คุณคาดไว้เท่านั้น ถ้าทั้งสองดูถูกแต่ทราฟฟิกยังตาย ปัญหาอยู่เลยโปรไฟล์ไปแล้ว อยู่ในนโยบายหรือตัวกรองของเกตเวย์

เมื่อการเชื่อมต่อล้มเหลวทั้งหมด รหัสจะชี้แคบลงว่าต้องกลับไปดูขั้นตอนใด:

  • 691: เกตเวย์ปฏิเสธข้อมูลรับรอง กลับไปที่ขั้นตอนที่ 3 ไม่ใช่ที่ทันเนล
  • 809: การจับมือ IKEv2 ไม่เคยเสร็จสิ้น ตรวจ UDP 500 และ 4500 รวมถึงความไว้วางใจในใบรับรอง
  • 789: คีย์ที่แชร์ล่วงหน้าของ L2TP/IPsec หายไปหรือผิด
  • 868: ชื่อเซิร์ฟเวอร์แปลงไม่ได้ แก้ DNS ก่อนแก้โปรไฟล์

เก็บคำสั่งที่ใช้งานได้ไว้ข้างการตั้งค่าที่มันเข้ารหัสไว้ เพื่อให้คนถัดไปสร้างใหม่ได้แทนที่จะย้อนวิศวกรรมโปรไฟล์จาก UI ถ้าจำเป็นต้องสร้างใหม่จริง ๆ ให้ลบรายการแล้วสร้างใหม่ด้วยพารามิเตอร์ชุดเดิม การปะโปรไฟล์ที่ตั้งค่าไว้ครึ่งเดียวจะทิ้งเส้นทางเก่าและสถานะการยืนยันตัวตนไว้ และถ้าไฟล์ไม่เคยเป็นแบบเนทีฟเลย ให้กลับไปที่ไคลเอนต์ที่เป็นเจ้าของมัน .ovpn ที่แต่งตัวเป็นโปรไฟล์ IKEv2 ไม่ใช่การนำเข้า แต่เป็นตั๋วขอความช่วยเหลือ

บทความที่เกี่ยวข้อง