VRF ใดไปถึงเพื่อน VPN และ VRF ใดพาแพ็กเก็ตไป

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

สองการค้นหา หนึ่งอุโมงค์

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

เอกสารของ Cisco สำหรับ IPsec ที่รู้จัก VRF เรียกทั้งสองว่าด่านหน้าบ้าน VRF และ VRF ภายใน ด่านหน้าเป็นตัวพาขนส่งที่เข้ารหัส และบริบทภายในเป็นตัวพาการรับส่งข้อมูลที่ได้รับการป้องกัน การตั้งชื่ออุโมงค์ตามชื่อลูกค้าไม่ได้ทำให้เส้นทางใดเส้นทางหนึ่งปรากฏขึ้น

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

ยืนยันการค้นหาขนส่งสำหรับเพื่อน

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

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

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

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

ยืนยันการค้นหาภายในสำหรับเซิร์ฟเวอร์

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

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

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

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

วางการตั้งค่าไว้ในที่ที่โมเดลคาดหวัง

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

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

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