strongSwan ESP-in-UDP: เมื่อไม่มี NAT ให้ตรวจจับ

การตรวจจับ NAT ค้นพบการแปลที่อยู่ ไม่ใช่นโยบายไฟร์วอลล์ การเชื่อมต่อไซต์ที่ไม่มี NAT ก็ยังอาจต้องเลือก ESP-in-UDP อย่างชัดเจน

การตรวจจับ NAT ตอบคำถามเดียวว่า ที่อยู่หรือพอร์ตเปลี่ยนไประหว่างทางหรือไม่ ไม่ได้ตอบว่าไฟร์วอลล์อนุญาตโปรโตคอล IP 50 หรือไม่ เกตเวย์ไซต์ที่ไม่มีการแปลเลยยังอาจอยู่หลังนโยบายที่ทิ้ง native ESP และข้อกำหนดนั้นต้องกำหนดค่าแทนการค้นพบ กลไกคือ ESP-in-UDP และเป็นการตัดสินใจ ไม่ใช่ทางเลือกสำรองที่เกิดขึ้นเอง

การตรวจจับคือเลขคณิตบนที่อยู่ ไม่ใช่การตรวจสอบไฟร์วอลล์

IKEv2 พา เพย์โหลดตรวจจับ NAT ที่มีแฮชของที่อยู่และพอร์ตต้นทางและปลายทาง แต่ละฝ่ายเปรียบเทียบสิ่งที่ได้รับกับสิ่งที่เห็นในเครื่อง ความไม่ตรงกันบอกว่ามีบางอย่างแปลแพ็กเก็ตนั้น ไม่มีสิ่งใดในการแลกเปลี่ยนนั้นทดสอบว่าเราเตอร์ตรงกลางส่งต่อโปรโตคอล 50 หรือไม่

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

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

encap เปลี่ยนการแลกเปลี่ยนอย่างไร

ในการติดตั้ง strongSwan สมัยใหม่ที่จัดการผ่าน swanctl.conf การตั้งค่า encap = yes บนการเชื่อมต่อมีผลต่อการแลกเปลี่ยนการตรวจจับ NAT เพื่อให้ทั้งสองฝ่ายใช้การห่อหุ้ม UDP สำหรับ ESP แพ็กเก็ตที่ได้รับการป้องกันจะเดินทางภายใน UDP โดยปกติบนพอร์ต 4500 และทั้งสองปลายต้องตกลงในรูปแบบนั้น

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

คู่มือ strongSwan เกี่ยวกับ NAT-traversal อธิบายพฤติกรรมนี้ รวมถึงปฏิสัมพันธ์กับการลอยของพอร์ตเมื่อใช้ MOBIKE

ใช้การตั้งค่าที่เป็นของแบ็กเอนด์ของคุณ

strongSwan มีแบ็กเอนด์การกำหนดค่าสองแบบ และคีย์แตกต่างกันระหว่างทั้งสอง swanctl.conf การเชื่อมต่อใช้ encap ขณะที่ ipsec.conf การเชื่อมต่อแบบเก่าใช้ forceencaps การใส่คีย์เวิร์ดของแบ็กเอนด์หนึ่งไปยังอีกอันจะได้การกำหนดค่าที่โหลดได้โดยไม่มีการร้องเรียนและไม่เปลี่ยนอะไร ซึ่งแย่กว่าข้อผิดพลาด

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

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

ตรวจสอบข้อมูลที่ห่อไว้ ไม่ใช่แค่พอร์ต

ดักจับที่เกตเวย์ขณะทราฟฟิกที่ได้รับการป้องกันไหลอยู่ แล้วเปรียบเทียบกับมุมมองของ strongSwan เอง:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP ปรากฏเป็นโปรโตคอล IP 50 และไม่คล้าย UDP เลย ESP ที่ห่อแล้วปรากฏเป็นเดตาแกรม UDP บน 4500 ซึ่งเพย์โหลดไม่ใช่ IKE ทราฟฟิก IKE บนพอร์ตเดียวกันไม่ใช่หลักฐานของการห่อหุ้ม เพราะ MOBIKE สามารถย้าย IKE ไปที่นั่นได้ในขณะที่เส้นทางข้อมูลยังเป็น native ดังนั้นอ่านเพย์โหลด ไม่ใช่หมายเลขพอร์ต

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

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

บทความที่เกี่ยวข้อง