ซับเน็ต VPN ได้รับระดับความปลอดภัยของอินเทอร์เฟซ ASA หรือไม่

ซับเน็ต VPN ที่ถอดรหัสแล้วไม่เคยสืบทอดระดับความปลอดภัยของอินเทอร์เฟซ ตรวจสอบ sysopt connection permit-vpn ตัวกรองกลุ่ม และสิทธิ์การจัดการแยกกัน

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

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

ระดับความปลอดภัยเป็นของอินเทอร์เฟซ

รัน show running-config interface แล้วคุณจะเห็น security-level ใต้แต่ละอินเทอร์เฟซจริงหรืออินเทอร์เฟซ VLAN ไม่ใช่ใต้กลุ่มอุโมงค์หรือ crypto map การอนุญาตเริ่มต้นจากสูงไปต่ำจะถูกประเมินระหว่างอินเทอร์เฟซเหล่านั้น จึงเป็นเหตุให้ตัวเลขเปลี่ยนพฤติกรรมการตรวจสอบและ ACL โดยนัยบนเส้นทางที่มันสังกัด

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

การข้าม ACL มีขอบเขตที่มีชื่อ

sysopt connection permit-vpn คือการตั้งค่าที่ผู้คนจำได้ครึ่ง ๆ เมื่อพูดว่าทราฟฟิก VPN ไม่สนใจ ACL มันข้าม ACL ของอินเทอร์เฟซสำหรับทราฟฟิกที่เข้าเกณฑ์เป็นทราฟฟิก VPN จริง และคู่มือพารามิเตอร์ 9.x จำกัดขอบเขตตามอินเทอร์เฟซและทิศทางแทนที่จะประกาศข้อยกเว้นระดับโลก

ตรวจสอบว่ามีการกำหนดค่าอะไรไว้ก่อนใช้ความจำตัดสิน:

  • show running-config all sysopt เพื่อดูค่าที่มีผลจริง ไม่ใช่เฉพาะบรรทัดที่ไม่ใช่ค่าเริ่มต้น
  • show running-config access-group เพื่อดูว่า ACL ใดถูกใช้กับอินเทอร์เฟซและทิศทางใด
  • show vpn-sessiondb detail l2l เพื่อยืนยันว่าเซสชันใช้กลุ่มอุโมงค์และตัวกรองใดจริง

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

อ่านตัวกรองที่ผูกกับเซสชัน

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

ยืนยันลำดับความสำคัญแทนที่จะสมมติ show running-config group-policy <name> แสดงค่าของกลุ่ม และ show running-config username <name> แสดงว่ามีค่าต่อผู้ใช้หรือไม่ ถ้ามีทั้งสอง ค่าของผู้ใช้ชนะ จากนั้นเปรียบเทียบรายการของ ACL นั้นกับโฟลว์ที่คุณสนใจ ในทิศทางที่ตัวกรองประเมิน

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

ตรวจสอบการอนุญาตหนึ่งรายการและการปฏิเสธหนึ่งรายการ

Packet-tracer เป็นวิธีที่เร็วที่สุดในการดูการตัดสินใจโดยไม่ต้องรอให้ผู้ใช้รายงาน ให้โฟลว์ฝั่งที่ถอดรหัสแล้ว และให้มันระบุขั้นตอน ACL, NAT และการตรวจสอบที่ผ่าน

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. อ่านบรรทัดผลลัพธ์: มันระบุ ACL ที่อนุญาตหรือทิ้งแพ็กเก็ต
  3. ทำซ้ำด้วยปลายทางการจัดการบนอินเทอร์เฟซ inside และยืนยันการปฏิเสธ
  4. ทำซ้ำอีกครั้งหลังการเปลี่ยนแปลงใด ๆ เพื่อให้บันทึกทั้งสถานะก่อนและหลัง

จากนั้นตรวจสอบด้วยทราฟฟิกจริง: คำขอแอปพลิเคชันหนึ่งรายการที่สำเร็จจากสาขา และความพยายาม SSH หนึ่งครั้งที่ล้มเหลวไปยัง ASA Packet-tracer จำลองเส้นทาง โฟลว์จริงพิสูจน์ว่าแบบจำลองตรงกัน

ย้อนกลับการเปลี่ยนแปลงที่ทำให้มันทำงาน

หากวิธีแก้คือปิดการข้าม ACL หรือขยายตัวกรอง ให้เก็บการกำหนดค่าก่อนหน้าไว้ ภาพ show run ของออบเจกต์ที่ได้รับผลกระทบซึ่งบันทึกไว้ก่อนการเปลี่ยนแปลงก็เพียงพอที่จะคืนค่าได้ การกำหนดค่า ASA อิงตามบรรทัด ดังนั้นการย้อนกลับหมายถึงการป้อนบรรทัดเก่าอีกครั้ง ไม่ใช่การคืนไฟล์

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

บทความที่เกี่ยวข้อง