IPsec ซ้อนใน IPsec: อุโมงค์ชั้นนอกต้องพาแอดเดรสใด

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

แบบจำลองสี่เกตเวย์

เกตเวย์ชั้นนอก A และ B สร้างอุโมงค์แรกระหว่างสองไซต์ ข้างหลัง A คือเกตเวย์ชั้นใน C ที่มีแอดเดรสทรานซิต10.60.0.2ข้างหลัง B คือเกตเวย์ชั้นใน D ที่มีแอดเดรสทรานซิต10.70.0.2เครือข่ายแอปพลิเคชันอยู่ข้างหลัง C และ D และทุกแอดเดรสในตัวอย่างจงใจไม่ทับซ้อนกัน

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

การแยกชั้นออกเป็นสี่โฮสต์หมายความว่าแต่ละเครื่องบังคับใช้ขอบเขตหนึ่งชั้น โฮสต์เดียวที่รันทั้งสองชั้นต้องประสานชุดนโยบายสองชุด ตารางเส้นทางสองตาราง และโหมดความล้มเหลวสองแบบบนเครื่องเดียว ซึ่งเป็นไปได้และสังเกตได้ยากกว่ามาก

แต่ละชั้นถอดการป้องกันของตัวเองเท่านั้น

C เข้ารหัสแพ็กเก็ตแอปพลิเคชันให้ D ผลลัพธ์ถูกส่งจาก C ไป D และนั่นคือสิ่งที่ไปถึง A ทุกอย่างปลายน้ำขึ้นอยู่กับการเขียนใหม่นั้น

A เข้ารหัสซ้ำให้ B B ถอดรหัสชั้นนอก เห็นแพ็กเก็ตจาก C ไป D และส่งต่อโดยยังเข้ารหัสอยู่ D ถอดการป้องกันชั้นในและส่งมอบแพ็กเก็ตแอปพลิเคชัน

ดังนั้น A และ B เห็นปลายทางชั้นในและเมทาดาทาของมัน แต่ไม่ใช่ฝ่ายที่ถอดรหัสเพย์โหลดของแอปพลิเคชัน นี่คือคุณสมบัติจริงของการออกแบบ ไม่ใช่ข้ออ้างว่า C D หรือโฮสต์แอปพลิเคชันน่าเชื่อถือ

ตัวเลือกชั้นนอกระบุชื่อเกตเวย์ชั้นใน

นี่คือจุดที่สิ่งก่อสร้างแบบนี้ส่วนใหญ่ล้มเหลว สำหรับอุโมงค์ชั้นนอกที่อิงนโยบาย ตัวเลือกที่คุณเจรจาต้องมีแอดเดรสที่ A และ B จัดการจริง:10.60.0.2/32และ10.70.0.2/32ตามลำดับภายในและระยะไกลที่ถูกต้อง

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

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

ตรวจสอบผลลัพธ์ด้วยswanctl --list-sasบนเกตเวย์แต่ละตัว และยืนยันว่าสมาคมความปลอดภัยลูกสาวรายงานแอดเดรสที่คุณตั้งใจ ไม่ใช่ที่คุณสันนิษฐานถ้ารายการแสดงซับเน็ตแอปพลิเคชัน แสดงว่านโยบายชั้นนอกเขียนผิดชั้น แก้ตัวเลือกก่อนจะดีบักเส้นทาง เพราะเส้นทางจะดูปกติแต่ตัวนับจะไม่ขยับ

การส่งต่อและกับดักการเรียกซ้ำ

ตัวเลือกไม่ใช่สิ่งทดแทนเส้นทาง A และ B ต้องส่งต่อทราฟฟิกระหว่าง C และ D ทั้งสองทิศทาง ซึ่งหมายถึงเปิดการส่งต่อ IP เส้นทางที่ชี้ไปยังอุโมงค์ และเส้นทางกลับที่มีอยู่ฝั่งตรงข้าม

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

กับดักคือการเรียกซ้ำ เส้นทางของ A ไปปลายทางชั้นนอกของ B ต้องไปตามเครือข่ายฐาน ไม่ใช่ตามอุโมงค์ที่ A กำลังสร้าง มิฉะนั้นการห่อหุ้มจะพยายามเดินทางในตัวเองและเชื่อมต่อไม่สำเร็จ

ตรวจดูการแปลก่อนเพิ่มชั้น

ดู NAT ต้นทางใด ๆ บน A และ B ก่อนปรับอย่างอื่น กฎที่เขียนแอดเดรสของ C ใหม่ก่อนนโยบาย IPsec จะมีผลอาจทำให้ตัวเลือกที่ตกลงกันเสีย และยังเปลี่ยนสิ่งที่ D ได้รับฝั่งตรงข้ามด้วย

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

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

พิสูจน์ fail-closed และตรวจ MTU

เส้นทางหายไปไม่ใช่ fail-closed โดยตัวเอง ตารางอื่น เส้นทางเริ่มต้น หรือกฎนโยบายอาจให้ทางสำรองอย่างเงียบ ๆ และวิธีเดียวที่จะรู้คือดาวน์อุโมงค์ชั้นนอกและสังเกตว่าทราฟฟิกแอปทำงานอย่างไร ทำอย่างตั้งใจในหน้าต่างบำรุงรักษา แทนที่จะค้นพบโดยบังเอิญ

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

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