Cisco ASA ไปยัง Azure VPN: คู่คำนำหน้าของตัวเลือกทราฟฟิก

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

เขียนสี่วัตถุก่อนกำหนดค่า

เริ่มจากรีลีสและแพลตฟอร์ม ASA ปลายทางสาธารณะ ชนิดและ SKU ของเกตเวย์ Azure VPN และเกตเวย์เครือข่ายภายในที่แทนฝั่งของคุณ ชื่อสี่ชื่อนี้คือคำศัพท์ของทุกสิ่งที่จะตามมา และแต่ละอย่างมีเจ้าของต่างกันเมื่อมีสิ่งเสีย

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

เลือกโมเดลการเชื่อมต่อหนึ่งแบบและเลิกผสมเทมเพลต

การออกแบบ crypto map และการออกแบบ tunnel interface เป็นการกำหนดค่าที่ต่างกัน และเทมเพลตของอันหนึ่งไม่กลายเป็นใช้ได้กับอีกอันโดยแก้ที่อยู่พีียร์ บันทึกว่าคุณกำลังสร้างอันไหนก่อนวางอะไรลงไป เพราะความไม่ตรงกันจะปรากฏภายหลังเป็นปัญหาตัวเลือก ไม่ใช่ข้อผิดพลาดการกำหนดค่า คู่มือการทำงานร่วมกันของ ASA ของ Microsoft ครอบคลุมทั้งสองรูปแบบและระบุว่าแต่ละแบบถือว่าใช้โมเดลเกตเวย์ Azure ใด ถ้าบันทึกของคุณไม่ระบุชื่อโมเดล คุณยังไม่มีดีไซน์

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

ขีดจำกัดเวอร์ชันก็อยู่ในสัญญาด้วย รายงานภาคสนามเก่าเกี่ยวกับขีดจำกัดของโดเมนการเข้ารหัสเป็นจุดข้อมูลเกี่ยวกับรีลีสบางรุ่น ไม่ใช่คุณสมบัติถาวรของทุก ASA

นับคู่คำนำหน้า ไม่ใช่การรวมกลุ่ม

เขียนเมทริกซ์ จาก A และ B ภายในไปยัง X และ Y ของ Azure คือสี่คู่ และแต่ละคู่ต้องมีความครอบคลุมหรือการยกเว้นอย่างชัดเจน การรวม A และ B เป็นกลุ่มเดียวจะรวมทุกสิ่งที่อยู่ระหว่างนั้นด้วย และนั่นคือวิธีที่ดีไซน์ค่อย ๆ เพิ่มรู

ตรวจสอบสิ่งที่พีียร์เจรจา ไม่ใช่สิ่งที่คุณบันทึก รายการเครือข่ายภายในและระยะไกลบน ASA คือเจตนา ส่วน CHILD SA คือผลลัพธ์

เมื่อคู่หายไป การแก้ไขมักเป็นบรรทัด access-list หรือรายการตัวเลือก ไม่ใช่อุโมงค์ใหม่

ตรวจสอบด้วยคำสั่งที่ระบุชื่อวัตถุ

บน ASA ยืนยันเซสชัน IKE จากนั้น SA ของ IPsec จากนั้นคู่ตัวเลือก แต่ละคำสั่งตอบคำถามต่างกัน และการรันเพียงคำสั่งแรกคือวิธีที่ «อุโมงค์ขึ้นแล้ว» กลายเป็นข้อสรุปเท็จ อ่านเอาต์พุตของพีียร์ที่คุณกำหนดค่าจริง ไม่ใช่ SA ที่บังเอิญอยู่ในลำดับแรก ฝั่ง Azure ตอบสามคำถามเดียวกันจากมุมมองของตน

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

จากนั้นถาม Azure เกี่ยวกับสถานะการเชื่อมต่อด้วย az network vpn-connection show --name <connection> --query connectionStatus เชื่อมต่อแล้วโดยไม่มีไบต์ในเส้นทางข้อมูลคือปัญหาตัวเลือก ไม่ใช่ปัญหาเส้นทาง

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

แยกขอบเขตการเข้ารหัสออกจากสิทธิ์การเข้าถึง

ตัวเลือกที่กว้างไม่ใช่สิทธิ์ ถ้าเลย์เอาต์ที่รองรับกว้างกว่านโยบายแอปพลิเคชัน ให้เก็บบริการที่แคบไว้ในกฎไฟร์วอลล์และปล่อยขอบเขตการเข้ารหัสไว้ในที่ที่ต้องอยู่

เส้นทางเวิร์กโหลดของ Azure และเส้นทางย้อนกลับภายในได้รับการตรวจสอบแยกกัน การประกาศ BGP ขอบเขตเครือข่ายแบบคงที่ และเส้นทางที่ผู้ใช้กำหนดต้องอธิบายเส้นทางเดียวกัน และไม่มีสิ่งใดจับการขนส่งของพีียร์ซ้ำได้

การย้อนกลับและหลักฐานว่ามันได้ผล

เก็บการกำหนดค่าที่กำลังทำงานก่อนหน้าไว้ก่อนเปลี่ยนตัวเลือก และรู้คำสั่งเดียวที่คืนมัน บน ASA นั่นหมายถึงสำเนาที่บันทึกไว้และเส้นทางการกู้คืนที่ตรงกัน ไม่ใช่ความจำว่าคุณแก้ไขอะไร เขียนคำสั่งกู้คืนลงในตั๋วเปลี่ยนระหว่างที่การเปลี่ยนแปลงยังเป็นสมมติ จากนั้นรันการตรวจสอบสามอย่างเดิมอีกครั้ง: สถานะ IKE คู่ SA ของ IPsec โฟลว์ที่อนุญาตหนึ่งรายการต่อคู่

ถ้าคู่ยังล้มเหลวหลังการกู้คืน การเปลี่ยนแปลงไม่ใช่สาเหตุ และคุณเพิ่งประหยัดการหยุดชะงักครั้งที่สองให้ตัวเอง