ข้อผิดพลาด 789 ของ L2TP/IPsec บน Windows: สร้างโปรไฟล์และปักหมุดข้อเสนอ

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

สร้างโปรไฟล์โดยไม่ใช้วิซาร์ด

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

Add-VpnConnection -Name "Contoso L2TP" `
  -ServerAddress 203.0.113.10 `
  -TunnelType L2tp `
  -EncryptionLevel Required `
  -AuthenticationMethod MSChapv2 `
  -RememberCredential -Force

ทำให้ -AuthenticationMethod ตรงกับสิ่งที่เกตเวย์เสนอ MSChapv2, EAP และ PAP ใช้แทนกันไม่ได้ และโปรไฟล์ที่เรียกวิธีที่เซิร์ฟเวอร์ไม่ยอมรับจะล้มเหลวก่อนที่จะมีการตรวจสอบบันทึกผู้ใช้ใด ๆ เก็บ -EncryptionLevel Required ไว้สำหรับทุกสิ่งจริง ๆ Optional อนุญาตให้ Windows ยอมรับอุโมงค์ที่ไม่เข้ารหัสหากฝ่ายตรงข้ามเสนอมา ซึ่งเป็นทางลัดในห้องแล็บไม่ใช่การตั้งค่าที่จะส่งมอบ

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

ปักหมุดข้อเสนอแทนการยอมรับค่าเริ่มต้น

Windows เติมการแปลง IPsec เอง นั่นคือเหตุผลที่เครื่องสองเครื่องที่มีการเชื่อมต่อดูเหมือนกันอาจล้มเหลวต่างกันต่อเกตเวย์เดียวกัน Set-VpnConnectionIPsecConfiguration คือวิธีที่รองรับในการปักหมุด:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES128 `
  -EncryptionMethod AES128 `
  -IntegrityCheckMethod SHA256 `
  -DHGroup Group14 `
  -PfsGroup None `
  -PassThru -Force

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

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

อ่านความล้มเหลวตามขั้นตอน ไม่ใช่ตามข้อความข้อผิดพลาด

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

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

บนเส้นทางใบรับรอง ตรวจสอบนาฬิกาของไคลเอนต์ ห่วงโซ่ความเชื่อถือ และตัวตนที่เกตเวย์คาดหวัง ก่อนพิจารณาผ่อนปรนการตรวจสอบ การปิดการตรวจสอบเปลี่ยน 789 ที่มองเห็นได้ให้เป็นอุโมงค์ที่เชื่อมต่อโดยเชื่อถือฝ่ายผิด และไม่มีอะไรในไคลเอนต์จะบอกคุณว่าเกิดขึ้น รายการข้อผิดพลาดการเข้าถึงระยะไกลของ Microsoft เป็นเอกสารอ้างอิงสำหรับรหัสเอง และแยกความล้มเหลวของชั้นความปลอดภัยออกจากความล้มเหลวในการลงชื่อเข้าใช้

ตรวจสอบจากทั้งสองด้านก่อนจะบอกว่าแก้ไขแล้ว

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

Get-VpnConnection -Name "Contoso L2TP" |
  Select-Object Name, ServerAddress, TunnelType, EncryptionLevel, AuthenticationMethod

หมุนจากบรรทัดคำสั่งเพื่อให้ได้ตัวเลขแทนกล่องโต้ตอบ: rasdial "Contoso L2TP" คืนรหัสความล้มเหลวเดียวกับที่อินเทอร์เฟซจะคืน และ rasdial "Contoso L2TP" /disconnect ล้างมันระหว่างความพยายาม จากนั้นอ่านฝั่งเกตเวย์สำหรับความพยายามเดียวกัน ipsec statusall ของ strongSwan หรือบันทึก IKE ของเราเตอร์บอกว่าข้อเสนอใดมาถึงและข้อใดถูกปฏิเสธ และการนำไปเปรียบเทียบกับค่าของ cmdlet คือขั้นตอนเดียวที่พิสูจน์ได้จริงว่าทั้งสองฝ่ายตกลงกัน

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

ทำให้เป็นอัตโนมัติ และย้อนกลับอย่างสะอาด

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

subprocess.run(["rasdial", "Contoso L2TP"], check=True)

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

โปรไฟล์คงอยู่ข้ามการรีบูตและมีอายุยืนกว่าการกำหนดค่าเกตเวย์ที่สร้างขึ้นมา เมื่อข้อเสนอของเกตเวย์เปลี่ยน ให้ลบรายการและสร้างใหม่แทนการซ้อนชุดค่าที่สองทับลงไป: Remove-VpnConnection -Name "Contoso L2TP" -Force จากนั้นทำสอง cmdlet ซ้ำด้วยชุดใหม่

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