GCP HA VPN ปฏิเสธ FortiGate: ชนิดของ ID ภายในไม่ตรงกัน
Google เปรียบเทียบตัวตนที่ FortiGate อ้าง ไม่ใช่แค่คีย์ที่แชร์ไว้ก่อนหน้า ID ภายในแบบ FQDN ไม่ผ่านการตรวจนั้น ขณะที่บันทึกยังบอกว่าการรับรองความถูกต้อง
AUTHENTICATION_FAILED จาก Google Cloud HA VPN มักทำให้ผู้คนกลับไปที่คีย์ที่แชร์ไว้ก่อนหน้า และโดยปกติคีย์นั้นถูกต้อง อุโมงค์หยุดอยู่ที่เฟส 1 เพราะ Google เปรียบเทียบสิ่งอื่นด้วย นั่นคือตัวตนที่คู่ค้าอ้างระหว่างการแลกเปลี่ยน IKE บน FortiGate ตัวตนนั้นเปลี่ยนชนิดได้โดยไม่มีใครแก้ไขที่อยู่ ให้อ่านบันทึกว่าเป็นความไม่ตรงกันของตัวตนเมื่อมีการป้อนคีย์ซ้ำสองครั้ง
ความล้มเหลวหนึ่งครั้ง การตรวจสองอย่าง
IKE ตรวจสอบคู่ค้าในสองขั้นตอนแยกกัน คีย์ที่แชร์ไว้ก่อนหน้าพิสูจน์ว่าทั้งสองฝั่งมีข้อมูลลับเดียวกัน และตัวตนที่อ้างบอกผู้ตอบว่าคู่ค้าอ้างว่าตนเป็นใคร Google ตรวจตัวตนนั้นเทียบกับคู่ค้าที่ตั้งค่าไว้ หากปล่อยไว้ FortiGate จะส่งตัวตนที่อิงที่อยู่ซึ่งได้มาจากอินเทอร์เฟซขาออก และการเปรียบเทียบก็ผ่านไปโดยไม่มีใครสังเกต
ทั้งสองขั้นตอนลงเอยในถังเดียวกันในบันทึก ซึ่งอธิบายวงจรที่คุ้นเคยคือการพิมพ์คีย์ซ้ำสี่ครั้งก่อนที่ใครจะอ่านเพย์โหลดตัวตน
สิ่งที่ FortiGate ใส่ในเพย์โหลดตัวตน
ปัญหาจะเริ่มเมื่อมีคนตั้งID ภายในเพื่อให้ทั้งสองฝั่งตรงกัน บิลด์ FortiOS ล่าสุดทำเครื่องหมายตัวตนนั้นเป็นชื่อโดเมนแบบเต็มรูปแบบ แม้ค่าที่พิมพ์จะเป็นที่อยู่ที่มีจุด Google จึงได้รับตัวตนแบบ FQDN ขณะที่คาดหวังที่อยู่ และปฏิเสธเซสชัน ไม่มีอะไรในข้อความบอกว่าครึ่งไหนล้มเหลว รายงานจึงถูกอ่านว่าเป็นการล้มเหลวในการรับรองความถูกต้อง
ทำซ้ำสักครั้งโดยเปิดการดีบัก IKE แล้วอ่านเพย์โหลดตัวตนที่ไฟร์วอลล์ส่งออกจริง
ในรอบเดียวกัน ให้ยืนยันข้อเท็จจริงราคาถูกสามข้อ คือเวอร์ชัน IKE ที่ทั้งสองฝั่งใช้ คีย์ที่ถูกต้องรวมถึงอักขระท้ายที่มองไม่เห็น และที่อยู่คู่ค้าที่ Google คาดหวัง สิ่งเหล่านี้ตอบคำถามคนละข้อ และคีย์ที่ตรงกันไม่บอกอะไรเกี่ยวกับตัวตน
ตัวเลือก และค่าใช้จ่ายของแต่ละทาง
แต่ละทางออกซ่อมคนละชั้น และไม่มีทางใดใช้ได้กับการติดตั้งทุกแบบ
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
การแก้ตัวตนบนไฟร์วอลล์เป็นคำตอบที่สะอาดที่สุดเมื่อเฟิร์มแวร์ให้เลือกชนิดและคงค่าไว้ ฟิลด์นี้มีในบางบิลด์และกรอกชนิดผิดในบางบิลด์ ดังนั้นควรทดสอบเวอร์ชันของคุณแทนที่จะเชื่อบันทึกการออกรุ่น
ที่อยู่สาธารณะที่กำหนดเส้นทางได้บนอินเทอร์เฟซที่เจรจา คือทางอ้อมที่เอกสารระบุไว้ เพราะตัวตนค่าเริ่มต้นจะตรงกับสิ่งที่ Google คาดหวังและไม่ต้องเขียนทับ การติดตั้งส่วนใหญ่ลงเอยที่นี่ หากไฟร์วอลล์ถือที่อยู่แบบนั้นได้
การสิ้นสุดที่คู่ค้าซึ่งตรวจสอบสิ่งที่คุณผลิตเป็นการเปลี่ยนโทโพโลยี ให้ถือเป็นการตัดสินใจเชิงออกแบบ ไม่ใช่ทางอ้อมที่คำอธิบายฟังดูนุ่มนวลกว่า
เมื่อ NAT ตัดตัวเลือกหนึ่งออก
หลัง NAT ทางออกผ่านที่อยู่สาธารณะหายไป และสิ่งที่เหลือขึ้นอยู่กับพฤติกรรมเฟิร์มแวร์ที่คุณควบคุมไม่ได้ นี่คือจุดที่ต้องเลือกอย่างตั้งใจระหว่างอัปเกรด ย้ายคู่ค้า หรือยอมรับปลายทางคลาวด์อื่น สิ่งเหล่านี้เป็นงบประมาณสามแบบที่ต่างกัน และการเลือกโดยบังเอิญคือวิธีที่ทางอ้อมชั่วคราวกลายเป็นสถาปัตยกรรม จดทางเลือกและเหตุผลไว้ข้างอุโมงค์
ก่อนตีความสิ่งใดจากทั้งหมดนี้ ให้ยืนยันสถานะอุโมงค์ฝั่ง Google และว่า IKE ไม่ได้ถูกทิ้งระหว่างทาง แพ็กเก็ตที่ถูกทิ้งจะหมดเวลา มันไม่ได้สร้างการปฏิเสธ
สิ่งที่ควรบันทึกไว้ขณะที่มันทำงาน
จดชนิดของตัวตน ค่าของมัน เวอร์ชันเฟิร์มแวร์ และที่อยู่คู่ค้าที่มีผลตอนที่อุโมงค์ขึ้นครั้งล่าสุด การอัปเดตเฟิร์มแวร์อาจเปลี่ยนค่าเริ่มต้นอีกครั้ง และความล้มเหลวครั้งถัดไปจะดูเหมือนคีย์ไม่ตรงกันทุกประการ เมื่อเก็บตัวตนไว้ข้างคีย์และที่อยู่คู่ค้า คนถัดไปก็เริ่มจากการตรวจราคาถูก
บันทึกนั้นยังเป็นวิธีเดียวที่จะรู้ว่ายังต้องใช้ทางอ้อมอยู่หรือไม่หลังการอัปเกรดครั้งถัดไป