วิธีจำลองการไหลของ VPN ด้วย ASA packet-tracer

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

การเดินชมด้านล่างถือว่า ACL กฎ NAT และบริบท tunnel-group อยู่ตรงหน้าคุณ หากไม่มี สิ่งที่พิมพ์ออกมาจะอธิบายนโยบายที่คุณตรวจสอบไม่ได้

ขั้นที่ 1: เขียนการไหลภายในด้วยคำง่าย ๆ

อธิบายแอปพลิเคชันก่อนพิมพ์อะไรลงไป โฮสต์ภายในที่เปิด SSH ไปยังเซิร์ฟเวอร์หลังเกตเวย์ระยะไกลคือการไหล TCP ภายในหนึ่งรายการที่มีพอร์ตต้นทางเฉพาะ นั่นคือการไหลที่ ACL และฟิลเตอร์ VPN ประเมิน ดังนั้นนั่นคือการไหลที่คุณพิมพ์

เขียนเป็นประโยคเดียว แล้วแปลทีละฟิลด์:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

ขั้นที่ 2: เลือกอินเทอร์เฟซขาเข้าและทิศทาง

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

พอร์ตก็มีทิศทางเช่นกัน พอร์ตบริการอยู่ในฟิลด์ปลายทางสำหรับคำขอที่เริ่มขึ้น และพอร์ตชั่วคราวของไคลเอนต์อยู่ในฟิลด์ต้นทาง โมเดลที่มีปลายทาง TCP 500 อธิบายแอปพลิเคชัน TCP ที่ฟังอยู่บน 500 มันไม่กลายเป็นการทดสอบ IKE เพียงเพราะตัวเลขปรากฏในคำสั่ง

ขั้นที่ 3: อ่านเฟสตามลำดับ

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

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

ขั้นที่ 4: ตรวจสอบว่าคุณเลือกการข้ามใด

รูปแบบ detailed รับตัวเลือกที่ข้ามการตรวจสอบ และ Cisco เอกสารตัวเลือก bypass-checks ที่ครอบคลุม ACL ฟิลเตอร์ VPN uRPF และการตรวจสอบการปลอมแปลง IPsec ALLOW ที่ได้จากการข้ามเหล่านั้นบอกว่าเส้นทางและ NAT จะทำงาน ไม่ใช่ว่านโยบายจะรับแพ็กเก็ตจริง บันทึกตัวเลือกไว้ข้างผลลัพธ์

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

ขั้นที่ 5: ปิดช่องว่างด้วยการแลกเปลี่ยนจริง

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

ตัวเลือก trace และ replay บางอย่างส่งแพ็กเก็ตหรือเก็บสถานะ ปฏิบัติตามพฤติกรรมที่เอกสารไว้สำหรับรีลีสของคุณและขั้นตอนการวินิจฉัยที่ได้รับอนุมัติ แทนที่จะถือทุกตัวแปรเป็นการค้นหาแบบอ่านอย่างเดียว

สิ่งที่การติดตามยังบอกคุณไม่ได้

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

เริ่มจาก tuple ภายใน หยุดที่เฟสแรกที่ขัดกับการออกแบบ แล้วจึงไปหาหลักฐานปลายทาง การติดตามคือ oracle ของนโยบาย ไม่ใช่ใบเสร็จการส่งมอบ