Cloud VPN ไปยัง Cisco ASA: สร้างใหม่หลังข้อเสนอไม่ตรงกัน

NEGOTIATION_FAILURE บนอุโมงค์ Cloud VPN ที่มี Cisco ASA อยู่อีกด้านหนึ่งเกือบทุกครั้งคือข้อเสนอหรือตัวเลือกไม่ตรงกัน และข้อเท็จจริงที่มีประโยชน์ข้อแรกคือไม่มีการแก้ไขใดจะแก้ได้ Cloud VPN ตรึงข้อเสนอ IKE ตั้งแต่สร้างออบเจ็กต์อุโมงค์ ไม่มีฟิลด์ให้เปลี่ยนอัลกอริทึมในที่เดิม ดังนั้นการซ่อมคือลบแล้วสร้างใหม่พร้อมจุดเริ่มต้นที่บันทึกไว้ มองว่าเป็นการสร้างใหม่ แล้วงานจะกลายเป็นรายการตรวจสอบ ไม่ใช่ช่วงบ่ายแห่งการเดา

อ่านความล้มเหลวก่อนลบสิ่งใด

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

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

บันทึกทั้งสองการตั้งค่าไว้ขณะที่ยังมีอยู่

การลบอุโมงค์ใช้เวลาครึ่งนาทีและทำลายหลักฐานเดียวที่คุณมี ก่อนหน้านั้นให้จดตัวเลือกภายในและระยะไกล ที่อยู่ของคู่ตรงข้าม ใครถือความลับร่วม และ crypto map หรือโปรไฟล์ IKEv2 ของ ASA ไว้ ASA ตอบคำถามสองข้อแยกกัน: อะไรถูกตั้งค่าไว้และอะไรกำลังขึ้นอยู่ตอนนี้:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

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

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

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

อัลกอริทึมที่ฝ่ายหนึ่งปฏิเสธที่จะเจรจา

Cloud VPN ไม่ได้เลือกจากช่วงอัลกอริทึม IKEv1 เหมือนคู่ตรงข้ามแบบเดิม การตั้งค่าคู่ตรงข้ามที่คาดหวังนั้นตายตัว: aes-cbc-128 สำหรับการเข้ารหัส sha1-96 สำหรับทั้งความสมบูรณ์และ PRF กลุ่ม Diffie-Hellman 2, 36,600 วินาทีสำหรับเฟส 1 และ 10,800 วินาทีสำหรับเฟส 2 นโยบายของ ASA ต้องเสนอชุดนั้นให้ตรงเป๊ะ ข้อเสนอที่สองบน ASA ไม่เป็นอันตรายตราบใดที่ข้อเสนอที่ตรงกันอยู่ในรายการด้วย

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

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

ลบ สร้างใหม่ และล้างสถานะเดิม

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

ล้างสมาคมความปลอดภัยหลังการเปลี่ยนแปลงบน ASA และก่อนอ่านผลลัพธ์ ASA อาจยังเสนอนโยบายเก่าต่อไปจนกว่า SA ปัจจุบันจะหมดอายุ ดังนั้นการตั้งค่าที่ถูกต้องจะดูเหมือนพังตลอดอายุการใช้งานเดิม และผู้เฝ้าดูสรุปว่าการสร้างใหม่ล้มเหลวทั้งที่ยังไม่เริ่ม:

clear crypto ikev2 sa
clear crypto ipsec sa

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

ตัวเลือกสะท้อนกัน แล้วตัวนับเป็นตัวตัดสิน

เฟส 2 ทำงานเฉพาะเมื่อทั้งสองฝั่งเห็นตรงกันเรื่องที่อยู่ที่ป้องกัน และความเห็นตรงกันนั้นเป็นการสะท้อนไม่ใช่การแบ่งปัน ตัวเลือกภายในของ Google ต้องตรงกับตัวเลือกที่ ASA เรียกว่าระยะไกล และตัวเลือกระยะไกลของ Google ต้องตรงกับสิ่งที่ ASA เรียกว่าภายใน อุโมงค์ที่มี 0.0.0.0/0 ฝั่งหนึ่งและซับเน็ตเดียวอีกฝั่งหนึ่งจะผ่านเฟส 1 แล้วล้มเหลวในเฟส 2 ด้วยข้อผิดพลาดหลักเดียวกัน ไม่มีฝ่ายใดขยายรายการของอีกฝ่ายได้

สำหรับตัวเลือกที่อิงนโยบาย ให้ระบุทุกคู่คำนำหน้าและเก็บรายการไว้ในตั๋ว ซับเน็ตที่เพิ่มภายหลังในสถานที่ต้องแก้ไขทั้งสองฝั่ง เพราะเส้นทางใหม่บน ASA ไม่ได้ขยายตัวเลือก และผลลัพธ์คืออุโมงค์ที่ขึ้นอยู่แต่ส่งผ่านทราฟฟิกเฉพาะคำนำหน้าที่มีอยู่ในวันแรก

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