VPN ระหว่างไซต์ทำงาน แต่บันทึกของ ASA ไม่มา: ตรวจสอบที่อยู่ต้นทาง
ข้อมูล LAN ที่ส่งต่อและบันทึกที่ไฟร์วอลล์สร้างขึ้นอาจออกมาจากต้นทางที่ต่างกัน ตรวจสอบการสร้าง ต้นทาง และตัวเลือกก่อนสร้างอุโมงค์ใหม่
โฮสต์ภายในเข้าถึงตัวรวบรวมระยะไกลและบรรทัด syslog ของพวกมันปรากฏขึ้น ข้อความของ ASA เองเกี่ยวกับเซสชันเดียวกันนั้นไม่เคยมาถึง ไม่มีอะไรผิดกับตัวรวบรวมหรือกับอุโมงค์ และนั่นคือส่วนที่ทำให้สับสน ไฟร์วอลล์ส่งบันทึกของมันจากต้นทางที่อุโมงค์ไม่เคยถูกสร้างขึ้นเพื่อปกป้อง
อะไรมาถึงและอะไรไม่มา
เริ่มจากการแยกสองโฟลว์ที่ดูเหมือนกันบนแดชบอร์ด ทราฟฟิกที่ส่งต่อผ่าน ASA: โฮสต์ LAN ส่งไปยังตัวรวบรวม ASA จับคู่กับนโยบายอุโมงค์ เข้ารหัส และตัวรวบรวมเห็นที่อยู่ของโฮสต์ ทราฟฟิกที่สร้างขึ้นเริ่มบน ASA เอง: อุปกรณ์สร้างแพ็กเก็ต syslog เลือกอินเทอร์เฟซขาออกและต้นทาง แล้วจึงถามว่ามีนโยบายอุโมงค์ใดตรงกันหรือไม่ โฟลว์แรกพิสูจน์ว่าอุโมงค์ทำงาน และไม่พูดอะไรเกี่ยวกับโฟลว์ที่สอง
เหตุการณ์ที่บัฟเฟอร์บนอุปกรณ์ก็ไม่ใช่หลักฐานของการส่งถึงระยะไกล เพราะบันทึกอาจมีอยู่ภายในเครื่องและไม่เคยถูกส่งเลย ตรวจสอบตัวนับการรับของตัวรวบรวมก่อนโทษอุโมงค์ เพราะตัวนับว่างเป็นข้อค้นพบที่ต่างจากตัวนับที่เพิ่มขึ้น
ข้อความที่สร้างขึ้นไม่ใช่ทราฟฟิกที่ส่งต่อ
เมื่อ ASA สร้างแพ็กเก็ตเอง มันไม่ได้เป็นพร็อกซีให้โฮสต์ LAN ต้นทางมาจากอินเทอร์เฟซขาออกหรือจากการตั้งค่าต้นทางที่ชัดเจน และแพ็กเก็ตเข้าสู่การค้นหาเส้นทางและการตรวจสอบนโยบายเดียวกับทุกสิ่งอื่นที่อุปกรณ์ส่ง หมายความว่าตัวเลือก VPN ต้องรวมที่อยู่ที่ ASA ใช้จริง และนั่นมักเป็นอินเทอร์เฟซภายนอกของมัน ไม่ใช่ซับเน็ตภายใน
หากนโยบายปกป้อง 10.20.0.0/24 และ ASA ใช้ที่อยู่ภายนอกเป็นต้นทาง แพ็กเก็ตบันทึกจะออกเป็นข้อความธรรมดาไปยังตัวรวบรวมที่ไม่สามารถเข้าถึงได้ หรือถูกทิ้ง ทั้งสองผลลัพธ์ดูเหมือนกันจากฝั่งตัวรวบรวม เหตุผลเดียวกันใช้กับทราฟฟิกการจัดการ ดังนั้น management-access จึงเป็นการตัดสินใจออกแบบแยกต่างหาก
ASA วางต้นทางใดบนเครือข่าย
ค้นหาต้นทางจากประสบการณ์จริง ไม่ใช่การสันนิษฐาน การดักจับบนอินเทอร์เฟซขาออกระหว่างข้อความทดสอบแสดงต้นทางและปลายทางจริง และใช้เวลาน้อยกว่าการอ่านส่วนการกำหนดค่าสามส่วน เปรียบเทียบที่อยู่นั้นกับตัวเลือกภายในของอุโมงค์
บางรีลีสอนุญาตให้ปักหมุดต้นทางบันทึกกับอินเทอร์เฟซ และเอกสารอ้างอิงคำสั่งสำหรับเวอร์ชันของคุณคือผู้มีอำนาจว่าตัวเลือกนั้นมีอยู่และเปลี่ยนแปลงอะไร คำสั่ง source-interface จากแพลตฟอร์ม Cisco อื่นไม่ถือว่าใช้ได้บน ASA โดยอัตโนมัติ
หากคุณเปลี่ยนต้นทาง ให้เปลี่ยนอย่างตั้งใจและบันทึกไว้ เพราะ ACL ของตัวรวบรวมและความสัมพันธ์ใด ๆ ที่สร้างบน syslog ขึ้นอยู่กับมัน
จับคู่ตัวเลือกกับโฟลว์บันทึก
เมื่อทราบต้นทางแล้ว ให้ตรวจสามอย่างตามลำดับ: ACL การเข้ารหัสหรือตัวเลือกที่อิงนโยบายซึ่งตัดสินว่าทราฟฟิกใดน่าสนใจ เส้นทางที่ตัดสินว่าแพ็กเก็ตไปที่ใด และกฎ NAT ใดที่อาจเขียนต้นทางใหม่ก่อนการเข้ารหัส แพ็กเก็ตที่ตรงกับเส้นทางแต่ไม่ตรงกับตัวเลือกจะไม่ถูกส่งผ่านอุโมงค์ และแพ็กเก็ตที่ NAT เขียนใหม่ อาจไม่ตรงกับทั้งสองอย่าง
ฝั่งตัวรวบรวมมีความต้องการของตัวเอง: ACL ที่อนุญาตต้นทางของ ASA เส้นทางกลับ และบริการที่รับฟังบนพอร์ตที่คุณกำหนดค่า การขนส่งก็สำคัญเช่นกัน เพราะการบันทึกผ่าน TCP และ TLS ทำงานต่างจาก UDP บนเส้นทางที่ถูกบล็อกบางส่วน เปลี่ยนทีละองค์ประกอบ มิฉะนั้นการดักจับครั้งถัดไปจะไม่บอกว่าการเปลี่ยนแปลงใดสำคัญ
ตรวจสอบที่ตัวรวบรวม แล้วบันทึกต้นทาง
ยืนยันว่าข้อความมาถึง แล้วจดที่อยู่ต้นทางที่ ASA ใช้ ตัวเลือกที่พามันมา และระดับความรุนแรงที่คุณทดสอบ
บันทึกนั้นเปลี่ยนการเปลี่ยนแปลง ACL ของตัวรวบรวมหรือการแก้ไขตัวเลือกครั้งถัดไปให้เป็นการตรวจสองนาทีแทนการค้นพบใหม่ มันยังบันทึกว่าโฟลว์ใดในสองโฟลว์เคยถูกตรวจสอบ และนั่นคือส่วนที่คู่มือส่วนใหญ่ละไว้ หากข้อความยังไม่มา ให้ลดเกณฑ์ความรุนแรงชั่วคราวและทดสอบกับปลายทางเดียว
คำถามที่พบบ่อย เกี่ยวกับการบันทึกของ ASA ของ Cisco บันทึกกรณีที่ต้นทางอยู่ภายนอกซึ่งต้องมีคำจำกัดความทราฟฟิกที่ป้องกันตามนั้น และตัวอย่างต้นทางภายในของมันรวมทั้งโฮสต์บันทึกภายในและ management-access ภายใน จัดการกับชุดค่าผสมที่บันทึกไว้และบริบทของซอฟต์แวร์ด้วยกัน แทนที่จะถือว่าบรรทัดที่คัดลอกมาหนึ่งบรรทัดใช้ได้กับการกำหนดค่าทุกแบบ
อุโมงค์ที่ขนส่งทราฟฟิก LAN ไม่ใช่อุโมงค์ที่ขนส่งเสียงของไฟร์วอลล์เอง