Add-VpnConnection: ทำไม PSK ถึงเสียและทำไมที่อยู่ยังคงเดิม
PowerShell ขยายคีย์ที่แชร์ล่วงหน้าภายในเครื่องหมายอัญประกาศคู่ก่อนที่ cmdlet จะบันทึก และอุโมงค์ที่ทำงานอยู่จะยังคงใช้ที่อยู่เดิมจนกว่าคุณจะเชื่อมต่อใหม่
โปรไฟล์ VPN ของ Windows คือรายการในสมุดโทรศัพท์ และ PowerShell คือวิธีหนึ่งในการแก้ไขรายการนั้น ความแตกต่างนี้นำไปสู่ความล้มเหลวสองอย่าง: คีย์ที่แชร์ล่วงหน้าที่ไปถึงเซิร์ฟเวอร์ในสภาพเสียหายแล้ว และที่อยู่เซิร์ฟเวอร์ที่ดูเหมือนอัปเดตแล้วแต่ไม่ใช่ที่อยู่ที่อุโมงค์ถัดไปจะเรียก ถ้ามองโปรไฟล์เป็นสถานะที่บันทึกไว้ไม่ใช่คำสั่งที่คุณรัน จะเห็นทั้งสองอย่างได้ง่ายขึ้น คำอธิบายเรียงตามลำดับการแก้ไข: สร้าง เปลี่ยน ขอบเขต อ่านกลับ
สร้างโปรไฟล์ด้วยคีย์ตามตัวอักษร
Add-VpnConnection รับคีย์ L2TP ที่แชร์ล่วงหน้าผ่าน -L2tpPsk PowerShell ประมวลผลสตริงก่อนที่ cmdlet จะได้รับ และภายในเครื่องหมายอัญประกาศคู่ เครื่องหมายดอลลาร์เริ่มการอ้างอิงตัวแปร ขณะที่ backtick เริ่ม escape คีย์ที่มีอย่างใดอย่างหนึ่งจะมาถึงสั้นลงหรือมีอักขระต่างออกไป และโปรไฟล์ก็ถูกสร้างสำเร็จด้วยความลับที่ผิด
จากนั้นความล้มเหลวจะปรากฏที่การพิสูจน์ตัวตน IPsec ซึ่งอุโมงค์ปฏิเสธที่จะขึ้น นี่คือเหตุผลที่ข้อผิดพลาดเรื่องอัญประกาศถูกรายงานเป็นปัญหาฝั่งเซิร์ฟเวอร์บ่อยครั้ง: โปรไฟล์มีอยู่ ชื่อถูกต้อง และความลับผิดอย่างเงียบ ๆ
| How you write it | What PowerShell does | Result |
|---|---|---|
| "p@ss$word!42" | Expands $word as a variable | Stored key is truncated |
| Double-quoted with an escape character | Consumes the next character as an escape | One character disappears |
| 'p@ss$word!42' | Keeps the literal characters | Stored key matches the secret |
อัญประกาศเดี่ยวคือทางแก้ และต้องครอบคลุมค่าทั้งหมด หากมีรายการอยู่แล้วด้วยคีย์ที่ไม่ดี -Force จะแทนที่ให้ หรือลบและสร้างโปรไฟล์ใหม่แล้วทดสอบด้วยการเชื่อมต่อใหม่:
Add-VpnConnection -Name "Contoso-L2TP" -ServerAddress vpn.contoso.example -TunnelType L2tp -L2tpPsk 'n3w$ecret!2026' -AuthenticationMethod Pap -RememberCredential -Forceเก็บความลับจริงไว้นอกประวัติ shell และสคริปต์ที่แชร์ อ่านตอนรันจากที่เก็บที่ได้รับอนุมัติและส่งตัวแปรแทนค่าตามตัวอักษร ซึ่งหลีกเลี่ยงปัญหาอัญประกาศได้ทั้งหมด
เปลี่ยนที่อยู่ แล้วเชื่อมต่อใหม่
Set-VpnConnection รับพารามิเตอร์ที่คั่นด้วยช่องว่าง ไม่ใช่ไวยากรณ์การกำหนดค่า การเขียน -ServerAddress = "203.0.113.10" จะส่งโทเค็นเพิ่ม และ cmdlet จะผิดพลาดหรือบันทึกสิ่งที่ไม่ตั้งใจ รูปแบบที่ถูกต้องคือ -Name "Office L2TP" -ServerAddress 203.0.113.10
แม้ไวยากรณ์จะถูกต้อง การเปลี่ยนแปลงก็ไม่ถึงอุโมงค์ที่ขึ้นอยู่แล้ว การเชื่อมต่อที่สร้างไว้จะคงที่อยู่ที่เรียกไปจนกว่าจะตัด ดังนั้นการทดสอบเซสชันเดิมจึงไม่พิสูจน์อะไรเกี่ยวกับค่าใหม่ ตัดการเชื่อมต่อ แก้ไข เชื่อมต่อใหม่ และยืนยันที่อยู่ของคู่ตรงข้ามในรายละเอียดการเชื่อมต่อ
คุณสมบัติบางอย่างเปลี่ยนที่เดิมไม่ได้ เมื่อ cmdlet ปฏิเสธ ให้บันทึกพารามิเตอร์ที่มีอยู่ ลบโปรไฟล์และสร้างใหม่ด้วยค่าที่แก้แล้ว และคงการตั้งค่าอุโมงค์และการพิสูจน์ตัวตนเดิมไว้ สคริปต์ที่ต้องเปลี่ยนแค่หมายเลขโทรศัพท์สามารถแก้ไขรายการในสมุดโทรศัพท์ผ่าน RAS API แทนการสร้างทุกอย่างใหม่ ไม่ว่าจะเลือกทางไหน ให้ยืนยันค่าที่บันทึกไว้ภายหลังแทนการเชื่อในความเงียบของคำสั่ง
รู้ว่าคุณแก้ไขสมุดโทรศัพท์เล่มใด
โปรไฟล์ต่อผู้ใช้อยู่ในไดเรกทอรีการเชื่อมต่อเครือข่ายของผู้ใช้คนนั้น และโปรไฟล์สำหรับผู้ใช้ทั้งหมดอยู่ในไดเรกทอรีระดับเครื่องใต้ทรีข้อมูลโปรแกรม ทั้งสองเป็นรายการต่างกันที่มีขอบเขตต่างกัน และการแก้ไขอันหนึ่งจะไม่แตะอีกอัน
นี่คือเหตุผลที่การเปลี่ยนแปลงอาจดูเหมือนหายไป: สคริปต์รันด้วยบัญชีหนึ่งและการทดสอบด้วยอีกบัญชี ใช้ -AllUserConnection เมื่อโปรไฟล์เป็นของเครื่อง และตรวจสอบขอบเขตเดียวกันเมื่ออ่านกลับ
อ่านโปรไฟล์กลับก่อนทดสอบ
ถาม Windows ว่าบันทึกอะไรไว้ ไม่ใช่คุณส่งอะไรไป:
Get-VpnConnection -Name "Office L2TP" | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethodเปรียบเทียบผลลัพธ์นั้นกับเจตนา แล้วเริ่มการเชื่อมต่อใหม่ หากการเรียกไม่สำเร็จ ให้ดูบันทึกไคลเอนต์ RAS ใน Event Viewer ก่อนเปลี่ยนโปรไฟล์อีกครั้ง เพราะบันทึกจะระบุขั้นตอนที่ล้มเหลว
รักษาการออกแบบการพิสูจน์ตัวตนให้ครบถ้วนขณะแก้ไข คำสั่งที่เปลี่ยนที่อยู่แต่ทิ้งใบรับรองหรือการกำหนดค่า EAP จะสร้างความล้มเหลวที่ดูไม่เกี่ยวข้องกับการแก้ไข และการส่งออกโปรไฟล์ที่ใช้งานได้ไว้ก่อนจะให้สิ่งที่กู้คืนได้แทนการเดา