ASA identity NAT กับการยกเว้น NAT บน IOS สำหรับทราฟฟิก VPN

สาขาหนึ่งรัน PAT สำหรับอินเทอร์เน็ตและ VPN แบบไซต์ทูไซต์บนเกตเวย์ Cisco ตัวเดียวกัน และ VPN หยุดทำงานทันทีที่เพิ่ม NAT ที่อยู่ภายในทันเนลไม่ตรงกับสิ่งที่ crypto ACL ป้องกันอีกต่อไป หรือปลายทางเห็นที่อยู่ที่ถูกแปลซึ่งไม่มีเส้นทางไปถึง Cisco แก้ปัญหานี้ในสองที่: ASA เลือกกฎ NAT ที่แมปที่อยู่กับตัวเอง ขณะที่ IOS เก็บโฟลว์ไว้นอกกฎการแปลด้วย deny ใน ACL ทั้งสองรักษาที่อยู่เดิมไว้ และไม่ใช่การข้ามการประมวลผล NAT

บันทึกโฟลว์ก่อนเลือกกฎ

เริ่มจากการเขียนโฟลว์ที่คุณต้องการป้องกัน: แหล่งต้นทาง LAN ปลายทางระยะไกล และคู่ที่อยู่ที่แน่นอนซึ่งนโยบาย IPsec ป้องกัน ทำก่อนแก้ไขกฎ เพราะชุดนี้บอกว่าตัวจำแนกหรือกฎ NAT ใดควรตรงกัน

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

ASA identity NAT เป็นกฎ ไม่ใช่การข้าม

บน ASA identity NAT คือกฎ NAT ที่ที่อยู่แปลแล้วเท่ากับที่อยู่เดิม กฎนี้ถูกเลือกเหมือนกฎอื่นและยังติดตั้งรายการแปล ดังนั้นแพ็กเก็ตไม่ได้ข้ามการประมวลผล NAT สิ่งที่เปลี่ยนคือที่อยู่บนเครือข่ายยังคงเดิม และนั่นคือสิ่งที่ IPsec ต้องการ

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

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

การเข้าถึงเพื่อบริหารจัดการตัว ASA เองเป็นกรณีแยก หากใช้ identity NAT กับทราฟฟิกบริหารจัดการ ข้อกำหนด route-lookup ตามรุ่นจะบังคับใช้ และข้อยกเว้นกว้างที่คัดลอกจากตัวอย่าง VPN จะไม่แก้ SSH

deny ใน ACL ของ NAT บน IOS หมายความว่าไม่ถูกเลือกที่นี่

บน IOS NAT อินเทอร์เน็ตขับเคลื่อนด้วยรายการต้นทาง และ ACL นั้นเป็นตัวจำแนก ไม่ใช่ตัวกรอง บรรทัด permit เลือกทราฟฟิกเพื่อแปล บรรทัด deny หมายความว่าแพ็กเก็ตไม่ถูกเลือกที่นี่ deny นั้นไม่ใช่คำสั่งให้ทิ้งแพ็กเก็ตเหมือน deny ใน ACL ของอินเทอร์เฟซ

การไม่ถูกเลือกที่นี่แคบกว่าการไม่ถูกแปลที่ใดเลย อีกกฎ NAT อีกอินเทอร์เฟซ หรือ route-map ยังแปลโฟลว์ได้ จึงต้องอ่านตาราง NAT ทั้งหมด แพ็กเก็ตยังต้องมีเส้นทาง มี crypto ACL ที่ตรงกัน และได้รับอนุญาตที่ขอบเขตควบคุมการเข้าถึงจริง

การจัดวาง IOS ขั้นต่ำวาง deny ไว้เหนือ permit ในรายการเดียวกันและชี้กฎ overload ไปที่รายการนั้น จากนั้น crypto ACL จะป้องกันคู่เดียวกับที่ deny ยกเว้นจากการแปล

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

คำถามหนึ่งข้อที่ทดสอบได้สำหรับทั้งสองแบบ

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

บน ASA แสดง nat detail และตารางการแปล บน IOS แสดง ip nat translations และตัวนับ ACL ที่เกี่ยวข้อง กฎที่ไม่เคยเพิ่มขึ้นไม่เคยถูกเลือก และนั่นชี้ไปที่ลำดับ อินเทอร์เฟซ หรือทิศทาง ไม่ใช่การกำหนดค่า crypto

การกำหนดค่ามักผิดพลาดตรงไหน

ความล้มเหลวทั่วไปเป็นเชิงกล deny อยู่ใต้ permit และไม่เคยตรง ตัวจำแนกถูกใช้ในทิศทางที่ผิด ดังนั้นโฟลว์ขากลับถูกแปล กฎ identity ครอบที่อยู่ถูกแต่คู่อินเทอร์เฟซผิด crypto ACL ป้องกันซับเน็ตที่ไม่ตรงกับสิ่งที่กฎ NAT นำเสนออีกต่อไป

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