IKEv2 บน Windows และ FortiGate: สามการตั้งค่าที่ผู้คนหลอมรวมกัน
การแลกเปลี่ยนกุญแจ IKE การป้องกัน CHILD SA และการพิสูจน์ตัวตนของคู่สนทนาเป็นสามแถวแยกกัน หมายเลขกลุ่มที่ตรงกันในสองหน้าต่างไม่ได้รวมทั้งสามเข้าด้วยกัน
ข้อตกลง IKEv2 ระหว่างไคลเอนต์ Windows กับเกตเวย์ FortiGate ยังคงล้มเหลว และการตามหาหมายเลขที่ไม่ตรงกันก็ยิ่งให้รายการหมายเลขที่ยาวขึ้น รายการจะจัดการได้ก็ต่อเมื่อแยกออกเป็นสามแถวที่ล้มเหลวแยกจากกัน คือการแลกเปลี่ยนกุญแจที่ปกป้อง IKE การป้องกันที่ใช้กับ CHILD SA และการพิสูจน์ตัวตนที่ยืนยันว่าแต่ละฝ่ายเป็นใคร หมายเลขกลุ่มปรากฏในสองแถวนั้นและมีความหมายต่างกัน
สามแถวที่ล้มเหลวแยกจากกัน
แถวแรกคือการแลกเปลี่ยนกุญแจภายใน IKE เอง ซึ่งสร้างกุญแจที่ปกป้องการเจรจา แถวที่สองคือข้อเสนอสำหรับ CHILD SA ซึ่งปกป้องทราฟฟิกที่อุโมงค์บรรทุก แถวที่สามคือการพิสูจน์ตัวตน ซึ่งตัดสินว่าแต่ละฝ่ายนำเสนออะไรและอีกฝ่ายตรวจสอบอย่างไร
ความล้มเหลวตกอยู่คนละที่ ความล้มเหลวของการแลกเปลี่ยนหยุดการเจรจาก่อนที่อุโมงค์ใดจะเกิดขึ้น ความล้มเหลวของ CHILD SA เกิดขึ้นหลังการพิสูจน์ตัวตนสำเร็จ บางครั้งเฉพาะตอนเปลี่ยนกุญแจ ความล้มเหลวของการพิสูจน์ตัวตนอาจดูเหมือนความล้มเหลวของการแลกเปลี่ยนในบันทึก หากคุณอ่านเพียงข้อผิดพลาดแรก
การแยกแถวไม่ใช่การทำบัญชี มันเปลี่ยนว่าการตั้งค่าใดควรค่าแก่การแก้ และมันป้องกันการเคลื่อนไหวที่แพงที่สุดในพื้นที่ทั้งหมดนี้ คือการสร้างใบรับรองที่ใช้งานได้ขึ้นใหม่เพื่อแก้ข้อเสนอที่ไม่ตรงกัน แถวหนึ่งเปลี่ยนไม่ควรบังคับให้อีกสองแถวต้องเปลี่ยนตาม ความเป็นอิสระนั้นคือเหตุผลทั้งหมดของการเขียนแยกกัน
สองฟิลด์ของ Windows ควบคุมอะไร
Windows แยกสองฟิลด์ออกจากกัน: DHGroup กำหนดการแลกเปลี่ยน IKE เอง ขณะที่ PfsGroup กำหนดนโยบาย IPsec ที่ปกป้องทราฟฟิกในอุโมงค์ ทั้งสองอยู่ในเฟสที่ต่างกัน การเทียบฟิลด์ IKE ของ Windows กับค่า phase-2 ของ FortiGate ทดสอบคู่ที่ผิด และหมายเลขอาจตรงกันในขณะที่การแลกเปลี่ยนพื้นฐานยังคงล้มเหลว
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAคำสั่งที่สองและที่สามรายงานสมาคมความปลอดภัยที่มีอยู่จริง ซึ่งเป็นสิ่งที่ใกล้คำตอบที่สุดที่ไคลเอนต์ให้คุณได้ สมาคมโหมดหลักที่ไม่มีสมาคมโหมดเร็วคือปัญหา CHILD SA และเป็นลายเซ็นของความไม่ตรงกันของ phase-2 ไม่ใช่ปัญหาใบรับรอง
บันทึกว่ามีการเสนออะไรและเลือกอะไรในการลองหนึ่งครั้ง รายการที่เสนอซึ่งมีข้อเสนอที่ยอมรับได้และข้อเสนอที่เลือกซึ่งไม่ตรงกับนโยบายของเกตเวย์คือความขัดแย้งของการตั้งค่า ไม่ใช่ปริศนาของการทำงานร่วมกัน
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
กลุ่มเส้นโค้งวงรีไม่ได้เลือกกุญแจลายเซ็นของคุณ
ข้อสรุปผิดที่คงทนที่สุดในพื้นที่นี้คือการเลือกกลุ่ม DH แบบเส้นโค้งวงรีต้องใช้ใบรับรองเส้นโค้งวงรี กลุ่ม DH ให้วัสดุสำหรับแลกเปลี่ยนกุญแจ อัลกอริทึมลายเซ็นถูกเจรจาโดยกรอบการพิสูจน์ตัวตน และทั้งสองเป็นการตัดสินใจแยกกันใน IKEv2
RFC 7427 มีอยู่ก็เพราะการตัดสินใจเหล่านั้นเคยพัวพันกันมาก่อน โดยกำหนดว่าอัลกอริทึมลายเซ็นถูกประกาศและเลือกอย่างไรโดยไม่ขึ้นกับการแลกเปลี่ยนกุญแจ เกตเวย์หนึ่งสามารถรองรับกลุ่มเส้นโค้งและตัวเลือกของรูปแบบลายเซ็นได้ในเวลาเดียวกัน
ดังนั้นเมื่อการเจรจาล้มเหลวหลังการเปลี่ยนกลุ่ม ให้ดูวิธีการพิสูจน์ตัวตนก่อนดูประเภทกุญแจของใบรับรอง การเปลี่ยนใบรับรองเป็นการดำเนินการที่ช้าและเสี่ยงซึ่งแทบไม่เคยเป็นคำตอบ และการทำก่อนจะทำลายความสามารถในการบอกว่าการเปลี่ยนแปลงใดช่วยได้จริง อ่านแถวการพิสูจน์ตัวตนก่อนแตะที่เก็บใบรับรอง
เก็บทั้งสองไว้ในแถวแยกกันของแผ่นข้อตกลงแล้วความผิดพลาดนั้นก็จะไม่น่าดึงดูดอีก แถวหนึ่งระบุกลุ่ม อีกแถวระบุรูปแบบลายเซ็นและตัวตน และไม่มียืนยันอะไรเกี่ยวกับอีกแถว
เก็บกุญแจส่วนตัวแต่ละดอกไว้กับเจ้าของจริง
เกตเวย์ที่นำเสนอใบรับรองของตนเองต้องมีกุญแจส่วนตัวที่ตรงกับมัน คู่สนทนาที่ตรวจสอบห่วงโซ่ต้องมีใบรับรอง CA และไม่จำเป็นต้องมีกุญแจลงนามของ CA การสับสนระหว่างสามสิ่งนั้นคือสาเหตุที่ผู้คนนำเข้ากุญแจส่วนตัวของ CA เข้าสู่อุปกรณ์ VPN เพื่อให้ใบรับรองไปปรากฏในหมวดอื่น
บน FortiOS บทบาทแยกจากกัน คือใบรับรองภายในพร้อมกุญแจ ใบรับรองระยะไกลที่ใช้ระบุคู่สนทนา และรายการ CA ระยะไกลที่สร้างความเชื่อถือในใบรับรองที่ CA นั้นลงนาม รายการ CA ระยะไกลที่ไม่มีกุญแจส่วนตัวไม่ได้ไม่สมบูรณ์ มันถูกต้องสำหรับวัตถุประสงค์ของมัน
กุญแจลงนามของ CA ที่นำเข้าขยายอำนาจของใครก็ตามที่อ่านอุปกรณ์นั้นได้ พวกมันยังไม่แก้การตรวจสอบคู่สนทนาปกติ เพราะการตรวจสอบต้องใช้ใบรับรองสาธารณะและการตัดสินความเชื่อถือ ไม่ใช่ความสามารถในการสร้างใบรับรองใหม่
เก็บกุญแจลงนามของ CA ไว้กับกระบวนการของผู้ออกเอง และบันทึกว่าอุปกรณ์ใดถือกุญแจใด ตารางเจ้าของสั้น ๆ มีค่ามากกว่าตารางอัลกอริทึมที่ยาวกว่าเมื่อการตรวจสอบถามว่าใครสวมรอยใครได้ ไม่มีใครนำเข้ากุญแจที่รู้ว่าเป็นเพียงสินค้าคงคลัง เขียนสินค้าคงคลังก่อนเหตุการณ์ ไม่ใช่หลัง