SSH ไปยัง ASA ระยะไกลผ่าน VPN ของไซต์: ทีละขั้นตอน

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

เลือกที่อยู่ที่คุณจัดการจริง ๆ

การออกแบบสามแบบดูคล้ายกันแต่ทำงานต่างกัน: เข้าถึงที่อยู่สาธารณะของ ASA ที่หันไปทาง VPN เข้าถึงส่วนต่อประสานภายในผ่าน IPsec และเข้าถึงส่วนต่อประสานจัดการโดยเฉพาะ จดที่อยู่ต้นทางของผู้ดูแลระบบ ที่อยู่ปลายทางที่แน่นอน และ TCP 22 ก่อนแตะสิทธิ์ใด ๆ ทุกอย่างหลังจากนั้นขึ้นอยู่กับคู่นี้

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

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

management-access จำเพาะต่อส่วนต่อประสาน

คำสั่ง management-access บอก ASA ให้ยอมรับการเชื่อมต่อจัดการไปยังส่วนต่อประสานที่ระบุชื่อเมื่อเข้ามาทาง VPN คำสั่งนี้ไม่สร้างเส้นทาง ไม่เพิ่มสิทธิ์ SSH และไม่ใช้กับทุกส่วนต่อประสานพร้อมกัน หากส่วนต่อประสานปลายทางไม่ใช่ตัวที่ระบุ การเชื่อมต่อจะถูกทิ้งก่อนการตรวจสอบสิทธิ์

มีข้อยกเว้นสองข้อที่กัดตรงนี้ ส่วนต่อประสานสำหรับจัดการเท่านั้นอยู่นอกกลไกนี้ และคู่มือการจัดการ ASA 9.20 ระบุว่าสแตก CiscoSSH ค่าเริ่มต้นไม่รองรับ SSH ข้ามส่วนต่อประสานผ่าน VPN ขณะที่สแตก ASA SSH รองรับ ยืนยันสแตกที่ใช้งานบนรีลีสที่ติดตั้งก่อนใช้เวลากับเส้นทาง

สี่ประตูก่อนพรอมต์เข้าสู่ระบบ

ระหว่างไคลเอนต์กับพรอมต์ชื่อผู้ใช้มีประตูอิสระสี่บาน: การตรงกันของเส้นทางและอุโมงค์สำหรับคู่จัดการ ACL ของส่วนต่อประสานที่อนุญาต TCP 22 ไปยังที่อยู่ ASA สิทธิ์ ssh ที่ครอบคลุมต้นทางของผู้ดูแลระบบ และการตรวจสอบสิทธิ์ AAA สำหรับผู้ใช้นั้น แต่ละบานสามารถทิ้งแพ็กเก็ตได้โดยไม่บอกไคลเอนต์ว่าประตูใดปิด

ใช้ packet-tracer ดูว่าประตูใดล้มเหลวก่อนเปลี่ยนอะไร: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed การติดตามระบุ ACL ขั้นตอน NAT และการตัดสินใจ to-the-box ซึ่งมักเพียงพอที่จะแยกปัญหาการกำหนดเส้นทางออกจากปัญหาการรับเข้า

เขียนสิทธิ์แบบแคบ ไม่ใช่แบบกว้าง

จำกัดสิทธิ์ให้อยู่ในซับเน็ตบริหารที่อนุมัติและส่วนต่อประสานที่รับทราฟฟิกของอุโมงค์: ssh 10.10.5.0 255.255.255.0 inside จับคู่กับวิธีการตรวจสอบสิทธิ์เช่น aaa authentication ssh console LOCAL และบัญชีโลคัลที่ระบุชื่อ แทนการเปิดทุกต้นทางบนส่วนต่อประสานภายนอก

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

ตรวจสอบจากโฮสต์ที่ระบุชื่อ แล้วแคบลงอีกครั้ง

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

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