กฎ ASA ตัวไหนเห็นทราฟฟิกหลังจาก VPN ถอดรหัสแล้ว

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

ACL เข้ารหัสตอบคำถามอื่น

ACL เข้ารหัสคือรายการจับคู่ มันบอกอุโมงค์ว่าจะเข้ารหัสอะไรระหว่างสองฝ่าย แพ็กเก็ตที่ไม่ตรงกับรายการก็ไม่ได้รับการป้องกัน การขยายรายการเปลี่ยนขอบเขตการป้องกันและไม่เปลี่ยนอย่างอื่น

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

การตั้งค่าข้ามจริง ๆ แล้วข้ามอะไร

sysopt connection permit-vpn อนุญาตให้ทราฟฟิกที่ได้รับการป้องกันข้ามการตรวจสอบ ACL ของอินเทอร์เฟซที่จะมีผลทางด้านขาเข้า มันเป็นความสะดวกสำหรับการติดตั้ง VPN และเป็นแบบทั่วโลก มันไม่แตะนโยบายกลุ่มและไม่แตะตัวกรองการอนุญาตรายผู้ใช้

อ่านค่าจริงแทนสมมติฐาน: show running-config all sysopt พิมพ์การตั้งค่าแม้จะไม่เคยกำหนดค่าอย่างชัดเจน และความสับสนจำนวนมากเริ่มต้นตรงนั้น

เนื่องจากการตั้งค่าเป็นแบบทั่วโลก การทดสอบเป็นการทดลองรวดเร็วบนซับเน็ตเดียวที่ล้มเหลวจึงเป็นการแลกที่ไม่ดี ทุกอุโมงค์อื่นบนไฟร์วอลล์นั้นแชร์ผลลัพธ์ เก็บไว้สำหรับการเปลี่ยนแปลงโดยเจตนาพร้อมแผนย้อนกลับ

อ่านตัวกรองในทิศทางถอดรหัส

ACL vpn-filter แบบ LAN-to-LAN เขียนจากมุมมองของอุโมงค์ ไม่ใช่อินเทอร์เฟซ เครือข่ายระยะไกลอยู่ในตำแหน่งต้นทางและเครือข่ายท้องถิ่นในตำแหน่งปลายทาง เพราะนั่นคือลักษณะของแพ็กเก็ตหลังการถอดรหัส จากนั้นตัวกรองเดียวกันถูกประเมินอีกครั้งในทิศทางตรงข้ามก่อนการเข้ารหัส โดยบทบาทของแอดเดรสสลับกัน

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

ยืนยันว่าตัวกรองใดถูกผูกไว้จริง: show running-config group-policy และ show vpn-sessiondb detail l2l ด้วยกันบอกว่าเซสชันสืบทอดอะไรมา การแก้ไข ACL ที่ไม่มีนโยบายใดอ้างถึงไม่เปลี่ยนอะไร

อย่าใช้ออบเจกต์ ACL เดียวสำหรับสองงาน

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

แยกทั้งสองไว้ ตั้งชื่อตามงานของมัน และให้ความต่างของทิศทางปรากฏในชื่อ

ตรวจสอบด้วยการเชื่อมต่อใหม่ ทั้งสองทิศทาง

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

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

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