failback บน ASA: อะไรเคลื่อนจริงเมื่อเส้นทางกลับมา
การที่เส้นทางกลับไปยังเส้นทางหลักไม่ได้หมายความว่ากระแสเดิมย้ายไปแล้ว ดู uplink ทันเนล ตารางการเชื่อมต่อ และผลลัพธ์ของแอปพร้อมกัน
บน ASA ที่มีสอง uplink นั้น failback ไม่ใช่การย้อนกลับของ failover เส้นทางไปยัง peer เปลี่ยน แล้วแพลตฟอร์มต้องประสานเครื่องสถานะสามเครื่องที่แยกจากกัน คือตารางเส้นทาง สมาคมความปลอดภัย IKE และ IPsec และตารางการเชื่อมต่อ แต่ละอย่างอาจตามหลังอย่างอื่น และความล่าช้านั้นคือสิ่งที่คนส่วนใหญ่เรียกกันว่าทันเนลที่ไม่กลับมา
failback เปลี่ยนอะไรจริง
การค้นหาเส้นทางคือส่วนที่มองเห็นได้ เมื่อวัตถุที่เฝ้าดูฟื้นตัว เส้นทางที่เฝ้าดูไปยังที่อยู่ภายนอกของ peer จะกลับมา และแพ็กเก็ตถัดไปที่ ASA ส่งจะตามลิงก์หลักอีกครั้ง ทุกอย่างหลังจากนั้นขึ้นอยู่กับว่าสถานะที่มีอยู่สอดคล้องกับเส้นทางใหม่หรือไม่
ARP และ NAT คือการพึ่งพาเงียบ ๆ next hop ใหม่ต้องมีเกตเวย์ที่แก้ได้และการแปลที่ยังตรงกับปลายทางไกล มิฉะนั้นแพ็กเก็ตแรกหลัง failback จะไม่ไปไหน และเส้นทางดูปกติในขณะที่ไม่มีอะไรทำงาน
สี่มุมมองบนเส้นเวลาเดียว
บันทึกสี่สิ่งเดียวกันก่อน ระหว่าง และหลังการเปลี่ยนผ่าน เพราะภาพเดียวบอกไม่ได้ว่าชั้นไหนเคลื่อน
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
เส้นทางที่ไม่เคยเปลี่ยนและเส้นทางที่เปลี่ยนในขณะที่การเชื่อมต่อเก่ายังคงสถานะการส่งต่อไว้ ให้ข้อร้องเรียนเดียวกันและหลักฐานต่างกันโดยสิ้นเชิง
ทำไมการเชื่อมต่อเดิมจึงอยู่บนเส้นทางสำรอง
ASA ไม่ตัดกระแสเพราะเส้นทางเปลี่ยน การเชื่อมต่อที่สร้างแล้วยังคงการตัดสินใจส่งต่อที่ใช้ตอนสร้าง และแพลตฟอร์มมีตัวควบคุมแยกสำหรับระยะเวลาที่อนุญาต คือ floating-connection timeout และ connection holddown คู่มือการตั้งค่าการเชื่อมต่อของ ASA 9.24 ของ Cisco มองว่าเป็นคำถามคนละข้อ และมันก็ทำงานเช่นนั้นจริง ๆ อย่างหนึ่งควบคุมการอยู่รอดของกระแสที่มีอยู่ อีกอย่างควบคุมว่าเมื่อใดกระแสใหม่จะใช้เส้นทางที่ต้องการได้
อ่านค่าที่มีผลสำหรับรุ่นของคุณก่อนจะเปลี่ยนค่าใดค่าหนึ่ง การลดค่าจะปิดเซสชันที่คนยังใช้อยู่ การเพิ่มค่าจะทำให้ failback ดูเหมือนไม่เคยเกิดขึ้น เพราะการเชื่อมต่อใหม่ยังใช้เส้นทางเดิมตลอดช่วงเวลานั้น
ทันเนลไม่ได้เจรจาคีย์ใหม่เพียงเพราะเส้นทางกลับมา
สมาคมความปลอดภัย IPsec มีอายุการใช้งานที่เจรจาของตัวเองและอยู่รอดจากการเปลี่ยนเส้นทางที่พามันมา ทันเนลจึงอาจยังอยู่ระหว่าง failback ในขณะที่ที่อยู่ภายนอกไม่ตรงกับเส้นทางที่ใช้แล้ว และนี่คือเหตุผลของ DPD และดีไซน์ที่ตรึงที่อยู่ของ peer ไว้แทนที่จะปล่อยให้ลอย
ดีไซน์ crypto-map และ VTI ทำงานต่างออกไปที่นี่ และเอกสารของ Cisco สำหรับ 9.24 VTI อธิบายตัวเลือกที่อิงเส้นทาง ข้อกล่าวอ้างเดิม ๆ ที่ว่า ASA ไม่สามารถรัน VPN แบบอิงเส้นทางได้นั้นไม่ใช้กับรุ่นที่รองรับ
อ่านหลักฐานตามลำดับนี้
เริ่มจากระนาบควบคุม: show route สำหรับเส้นทางที่เลือก show interface สำหรับสถานะลิงก์ และตัวนับของ SLA monitor สำหรับวัตถุที่เฝ้าดู จากนั้นอ่าน show crypto ikev2 sa หรือสิ่งที่เทียบเท่าใน IKEv1 เพื่อดูว่า peer ใดยังมีชีวิต ตามด้วย show crypto ipsec sa สำหรับกระแสที่ได้รับการป้องกัน จากนั้นจำกัดตารางการเชื่อมต่อด้วย show conn address <host> และเปรียบเทียบคอลัมน์อินเทอร์เฟซในรายการเก่าและใหม่ จดผลลัพธ์พร้อมเวลา เพราะลำดับของมันคือการวินิจฉัย
ปิดท้ายด้วยการทดสอบแอป: กระแสหนึ่งที่มีอยู่แล้วและอีกอันที่สร้างหลังเส้นทางกลับมา ถ้ากระแสเก่าล้มเหลวและอันใหม่ทำงาน แสดงว่าคุณมีเรื่องราวของสถานะการเชื่อมต่อ ถ้าทั้งคู่ล้มเหลว ทันเนลหรือนโยบายผิด และตารางการเชื่อมต่อเป็นเพียงสิ่งเบี่ยงเบนความสนใจ
เก็บบันทึกนั้นให้มีรูปแบบเดียวกันในทั้งสามระยะ และระบุรุ่นอย่างแม่นยำ เมื่อเส้นเวลายังชี้ไปที่การเปลี่ยนผ่านเดียว ซื้อบันทึกนั้นส่งฝ่ายสนับสนุนแทนการเดา ID ของบั๊ก