DHCP รีเลย์บน ASA ผ่าน VPN แบบไซต์ทูไซต์: คำแนะนำทีละขั้นตอน

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

ช่วงแรก: เปิดรีเลย์บนอินเทอร์เฟซที่หันไปทางไคลเอนต์

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

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

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

ช่วงที่สอง: พาทราฟฟิกที่ ASA สร้างขึ้นผ่านอุโมงค์

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

ยืนยันว่าทราฟฟิกที่สนใจครอบคลุมต้นทางรีเลย์ของ ASA และที่อยู่เซิร์ฟเวอร์ และทิศทางขากลับก็ได้รับอนุญาตด้วย ในดีไซน์ที่อิง VTI การตัดสินใจเส้นทางง่ายกว่า แต่การรองรับรีเลย์บน VTI มาในรีลีสที่เฉพาะเจาะจง; คู่มือ DHCP ของ ASA ระบุ 9.14(1) ดังนั้นตรวจสอบอิมเมจก่อนคัดลอกตัวอย่าง VTI ไปยังอุปกรณ์รุ่นเก่า

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

ช่วงที่สาม: อ่านคำตอบและตัวเลือก setroute

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

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

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

สิ่งที่ผมตรวจก่อนจะบอกว่าแก้แล้ว

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

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

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