ทำไมผู้ใช้ระยะไกลของ ASA จึงเข้าถึงซับเน็ตได้แต่ไม่ถึงแอป
เส้นทางพิสูจน์ว่าอุโมงค์ทำงาน ไม่ได้พิสูจน์ว่าผู้ใช้ได้รับอนุญาตให้เปิดแอป อ่านฟิลเตอร์ที่เซสชันได้รับ แล้วทดสอบการเชื่อมต่อที่อนุญาตและที่ถูกปฏิเสธ
ผู้ใช้ของคุณเชื่อมต่อ ได้รับที่อยู่ ปิงเซิร์ฟเวอร์ในซับเน็ตของแอป และยังเปิดบริการบนเครื่องนั้นไม่ได้ การผสมกันแบบนี้เป็นเรื่องปกติบน ASA เพราะ อุโมงค์ที่สำเร็จและการอนุญาตที่ใช้งานได้ถูกกำหนดโดยการตั้งค่าที่ต่างกัน รายการอุโมงค์แบบแยกส่วนเลือกว่าปลายทางใดเข้าสู่อุโมงค์ ฟิลเตอร์ VPN และกฎการเข้าถึงของปลายทางเองกำหนดว่าคำขอที่ถอดรหัสแล้วเข้าถึงอะไรได้บ้าง ไล่สามการตัดสินใจตามลำดับแทนการขยายรายการเส้นทางจนกว่าอะไรจะเปลี่ยน
สามการตัดสินใจที่สับสนได้ง่าย
การรับเข้าตอบว่าผู้ใช้สร้างอุโมงค์ได้หรือไม่ตั้งแต่แรก ได้แก่ ข้อมูลรับรอง ใบรับรอง และปัจจัยที่สองใด ๆ การเลือกเส้นทางตอบว่าไคลเอนต์ส่งปลายทางใดเข้าสู่อุโมงค์นั้น การอนุญาตตอบว่าคำขอที่ถอดรหัสแล้วเข้าถึงบริการได้หรือไม่ มีเพียงข้อที่สามเท่านั้นที่สร้างข้อผิดพลาดที่ผู้ใช้รายงาน
วิธีแยกแยะอย่างรวดเร็วคือถามว่าการเปลี่ยนแปลงจะพังอะไร การลบเส้นทางออกจากรายการแยกส่วนจะหยุดทราฟฟิกไปยังซับเน็ตนั้นโดยไม่ให้สิ่งใด ส่วนการเพิ่ม ACE ในฟิลเตอร์ VPN จะให้ปลายทางโดยไม่เปลี่ยนสิ่งที่ไคลเอนต์ใส่อุโมงค์
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
อ่านฟิลเตอร์ที่เซสชันได้รับจริง
เริ่มจากเซสชันที่ใช้งานอยู่ ไม่ใช่จากการกำหนดค่าที่คุณคิดว่าใช้บังคับ show vpn-sessiondb detail anyconnect พิมพ์นโยบายกลุ่มที่กำหนดและชื่อฟิลเตอร์ที่ผูกกับเซสชันนั้น หากช่องนี้ว่าง แสดงว่าไม่มีฟิลเตอร์ใดบังคับอะไร และการบล็อกมาจากที่อื่น
จากนั้นอ่านนโยบายที่เป็นเจ้าของค่า รวมถึงค่าเริ่มต้น เพราะฟิลเตอร์อาจสืบทอดมาแทนที่จะเขียนไว้ตรงที่คุณดู:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
เปรียบเทียบชื่อฟิลเตอร์บนเซสชันกับ ACL ที่คุณเพิ่งแก้ไข ACL ที่ชื่อคล้ายกันซึ่งผู้ใช้ไม่เคยได้รับไม่สามารถเปลี่ยนนโยบายทรัพยากรของเซสชันนั้นได้ และนี่คือสาเหตุที่พบบ่อยที่สุดที่การเปลี่ยนแปลงซึ่งดูถูกต้องไม่มีผล
ลำดับความสำคัญอธิบายส่วนที่เหลือ สำหรับการตั้งค่าฟิลเตอร์ บันทึก DAP มาก่อนคุณลักษณะชื่อผู้ใช้ และคุณลักษณะชื่อผู้ใช้มาก่อนนโยบายกลุ่ม เมื่อเซสชันแสดงฟิลเตอร์ที่คุณไม่ได้คาดไว้ ให้มองหานโยบาย DAP ที่ตรงกับผู้ใช้รายนั้นก่อนแตะกลุ่ม
รายการแยกส่วนและฟิลเตอร์เป็นคนละช่อง
บน ASA 9.x นโยบายกลุ่มเก็บ split-tunnel-network-list และ vpn-filter เป็นการตั้งค่าที่ต่างกัน และคู่มือการนโยบายกลุ่ม 9.22 บันทึกทั้งสองแยกกันด้วยเหตุผลนั้น รายการเครือข่ายเป็นคำใบ้เส้นทางสำหรับไคลเอนต์ ส่วนฟิลเตอร์เป็นรายการควบคุมการเข้าถึงที่ใช้กับทราฟฟิกที่ถอดรหัสแล้ว
ความแตกต่างนี้สำคัญเมื่อผู้ใช้ต้องการบริการ HTTPS เดียวในซับเน็ต ใส่ซับเน็ตในรายการแยกส่วนเพื่อให้แพ็กเก็ตเข้าสู่อุโมงค์ แล้วอนุญาตเฉพาะบริการนั้นในฟิลเตอร์ การขยายรายการเส้นทางไม่ได้ให้สิทธิ์อะไร และการย่อให้เล็กลงไม่ใช่กลไกบังคับใช้
ตรวจสอบว่า ACL ของอินเทอร์เฟซอยู่ในเส้นทางหรือไม่
ทราฟฟิกการเข้าถึงระยะไกลที่ถอดรหัสแล้วไม่ได้ผ่าน ACL ของอินเทอร์เฟซภายนอกเสมอไปอย่างที่ผู้คนคิด sysopt connection permit-vpn เมื่อเปิดใช้งาน ASA จะใช้การข้าม VPN ที่บันทึกไว้กับทราฟฟิกนั้น ขณะที่ฟิลเตอร์ VPN ที่เกี่ยวข้องยังมีผลหลังจากนั้น ตรวจสอบการตั้งค่าด้วย show run all sysopt แทนการคาดเดาจากแผนภาพโทโพโลยี
ไม่ว่าอย่างไร ไฟร์วอลล์ของโฮสต์ปลายทางและการอนุญาตของแอปยังอยู่ในเส้นทาง กฎ ASA ที่อนุญาต TCP 443 ไม่ได้ทำให้แอปยอมรับผู้ใช้
ยอมรับการเปลี่ยนแปลงด้วยการเชื่อมต่อที่ถูกปฏิเสธด้วย
การทดสอบที่อนุญาตเพียงอย่างเดียวพิสูจน์ได้น้อยมาก เพราะอุโมงค์ที่ทำงานได้สร้างแพ็กเก็ตแรกเหมือนกันไม่ว่าจะมีฟิลเตอร์หรือไม่ เปิดบริการที่ตั้งใจจากไคลเอนต์ แล้วลองปลายทางที่ควรปิดอยู่และยืนยันว่าล้มเหลวด้วยเหตุผลที่ถูกต้อง
บันทึกสี่ข้อเมื่อปิดตั๋ว ได้แก่ ตัวตนที่ได้รับอนุญาต นโยบายและฟิลเตอร์ที่เซสชันได้รับจริง ปลายทางในรายการแยกส่วน และทรัพยากรที่ผู้ใช้ได้รับอนุญาตให้เข้าถึง สี่ข้อนี้อธิบายว่าทราฟฟิกถูกควบคุมที่ใดโดยไม่เปลี่ยนรายการเส้นทางให้เป็นไฟร์วอลล์
หากบริการยังปฏิเสธหลังจากฟิลเตอร์อนุญาต ให้ไปที่โฮสต์ ได้แก่ ที่อยู่ที่รับฟัง ไฟร์วอลล์ของโฮสต์ และการแมปผู้ใช้ของแอปเอง เมื่อถึงจุดนั้นอุโมงค์ได้ทำหน้าที่ของมันแล้ว และการเปลี่ยนแปลง ASA เพิ่มเติมมีแต่เพิ่มความเสี่ยง