เส้นทางเริ่มต้นแบบ tunneled บน Cisco ASA: ใช้จริงเมื่อใด

ผู้ใช้ที่เข้าถึงจากระยะไกลไปไม่ถึงอะไรเลยเลย ASA ขณะที่เซิร์ฟเวอร์เดียวกันตอบ ping จาก LAN ภายใน อุโมงค์เชื่อมต่อขึ้นมา ไคลเอนต์ได้รับที่อยู่จากพูล แต่แพ็กเก็ตก็ยังออกผ่านเส้นทางเริ่มต้นของอินเทอร์เน็ตหรือหายไปเลย รูปแบบนี้มักหมายความว่าทราฟฟิกที่ถอดรหัสแล้วไม่พบเส้นทางของตัวเองและตกลงมาที่เส้นทางเริ่มต้นปกติ การแก้ไขไม่ใช่กฎ NAT อีกข้อ แต่คือเส้นทางเริ่มต้นแบบ tunneled

เริ่มจากอาการ ไม่ใช่จากการตั้งค่า

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

อุโมงค์ดูปกติใน show vpn-sessiondb และนั่นคือเหตุผลที่ผู้คนยังคงดีบัก IKE กันต่อไป

สิ่งที่แยกกรณีนี้จากการทิ้งโดย ACL คือทิศทาง การทิ้งโดย ACL ถูกบันทึกและนับ ขณะที่เส้นทางที่หายไปทำให้การค้นหาล้มเหลวโดยไม่มีรายการที่ตรงกัน รัน show route สำหรับปลายทางของไคลเอนต์แล้วอ่านว่า ASA เลือกอะไรจริง ๆ รวมถึงว่าเลือกเส้นทางเริ่มต้นหรือไม่และเส้นไหน

การค้นหาแบบ tunneled ต่างกันอย่างไร

คู่มือของ Cisco เรื่อง การกำหนดเส้นทางแบบสแตติกบน ASA 9.23 อธิบายเส้นทางเริ่มต้นแยกต่างหากสำหรับทราฟฟิก VPN ที่ถอดรหัสแล้วซึ่งไม่มีเส้นทางแบบสแตติกหรือเส้นทางที่เรียนรู้ คำสำคัญ tunneled ทำเครื่องหมายเส้นทางนั้น ดังนั้นแพ็กเก็ตที่ถอดรหัสแล้วจึงสามารถตกลงไปยังฮอปถัดไปที่ต่างจากที่ ASA ใช้สำหรับการขนส่งของตัวเองได้ เส้นทางที่เจาะจงกว่ายังชนะอยู่ นั่นคือเหตุผลที่ไคลเอนต์เข้าถึง 10.0.0.0/8 ผ่านเกตเวย์ภายในได้แต่สูญเสียทุกอย่างอื่น

การจัดวางขั้นต่ำเก็บเส้นทางเริ่มต้นสองเส้นที่มีฮอปถัดไปต่างกัน เส้นหนึ่งพาทราฟฟิกของ ASA เอง อีกเส้นพาทราฟฟิกที่ถอดรหัสแล้วซึ่งไม่มีเส้นทางที่ดีกว่า ฮอปถัดไปทั้งสองยังต้องเข้าถึงได้จากอินเทอร์เฟซที่คุณผูกไว้

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

ถ้าเส้นทางเริ่มต้นทั้งสองชี้ไปยังฮอปถัดไปเดียวกัน คำสำคัญก็ไม่เปลี่ยนอะไรและอาการก็จะไม่ขยับ

ข้อจำกัดที่กำหนดว่ามันจะได้ผลหรือไม่

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

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

การติดตามเส้นทางเป็นกับดักอีกอย่างหนึ่ง วัตถุที่ถูกติดตามมักคุ้มครองเส้นทางเริ่มต้นปกติ ไม่ใช่เส้นทางแบบ tunneled

สิ่งที่คำสำคัญไม่ได้ทำ

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

มันไม่ได้เปลี่ยนฮอปถัดไปให้เป็นพร็อกซีด้วย ถ้าปลายทางคาดว่าจะมีการแลกเปลี่ยน HTTP CONNECT การส่งแพ็กเก็ต IP ดิบไปยังโฮสต์พร็อกซีก็ให้เพียงโฮสต์ที่ไม่ได้กำหนดเส้นทางให้แพ็กเก็ตเหล่านั้น ให้กำหนดค่ากลไกพร็อกซีที่ไคลเอนต์รองรับแทน

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

ตรวจสอบเส้นทางตั้งแต่ต้นจนจบ

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

ถ้าเกตเวย์ตอบแต่ไคลเอนต์ไม่เคยเห็นคำตอบ ให้ดูการแปลที่อยู่ต้นทางและเส้นทางขากลับก่อนจะแตะตารางเส้นทางอีกครั้ง

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