จาก strongSwan ถึง AWS Site-to-Site: ทำไม Child SA จึงไม่เลือกอะไรเลย

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

แปลชื่อของ AWS เป็นคำศัพท์ของ strongSwan

AWS อธิบายการเชื่อมต่อจากฝั่งลูกค้า: ที่อยู่เกตเวย์ของลูกค้าและ CIDR ภายในเป็นของคุณ และ CIDR ระยะไกลเป็นของ VPC strongSwan เรียกปลายทั้งสองว่า left และ right โดยคำนำหน้าของคุณอยู่ใน leftsubnet และคำนำหน้าของ VPC อยู่ใน rightsubnet การสลับคู่หนึ่งคู่จะทำให้เกิดอุโมงค์ที่เจรจาและเลือกทราฟฟิกผิด

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

ความไม่ตรงกันตรงนี้ดูเหมือนความล้มเหลวของการกำหนดเส้นทาง แต่ไม่ใช่

ตรึงที่อยู่ที่ AWS มองเห็นจริง

เราเตอร์ที่อยู่หลัง NAT อาจส่ง IKE จากอินเทอร์เฟซที่อีกฝั่งไม่เคยรู้จัก ที่อยู่เกตเวย์ที่บันทึกใน AWS ต้องเป็นที่อยู่ที่ AWS สังเกตเห็นบนเครือข่าย และเราเตอร์ต้องถูกตรึงไว้กับที่อยู่ภายในเดียวกันแทนที่จะตามเส้นทางเริ่มต้น

conn %default
    local_addrs = 203.0.113.10

ใน strongSwan นั้น local_addrs เลือกที่อยู่ต้นทางสำหรับ IKE และการกำหนดค่า OpenSwan แบบเก่าเขียนแนวคิดเดียวกันว่า left ชี้ไปยังอินเทอร์เฟซที่มีที่อยู่สาธารณะ จากนั้นตรวจสอบบนอุปกรณ์ NAT เองว่า UDP 500 และ 4500 ไปถึงโฮสต์นั้นได้ เพราะกฎที่ตกค้างจากเราเตอร์ก่อนหน้าจะทิ้งแพ็กเก็ตเหล่านั้นอย่างเงียบ ๆ คู่ตัวเลือกที่ถูกต้องแต่ที่อยู่ต้นทางผิดก็ยังล้มเหลว และบันทึกจะโทษข้อเสนอ ความเข้าใจผิดนั้นคือเหตุผลที่ที่อยู่ต้นทางสมควรได้รับการตรวจสอบของตัวเอง

ยืนยันกฎการส่งต่อแทนที่จะสันนิษฐาน เพราะกฎที่เคยถูกต้องสำหรับเราเตอร์ก่อนหน้ามักตกค้างอยู่

จัดการเฟส 1 และเฟส 2 แยกจากกัน

AWS แสดงตัวเลือก IKE และ ESP เป็นรายการแยกกัน ชุด IKE ที่ทั้งสองฝั่งยอมรับไม่ได้บอกอะไรเกี่ยวกับข้อเสนอ ESP เพราะทั้งสองรายการเป็นอิสระต่อกัน อ่านทั้งสองจากไฟล์กำหนดค่าที่สร้างขึ้นแล้วเปรียบเทียบทีละรายการ

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

ไวยากรณ์ไม่เคลื่อนย้ายข้ามการใช้งาน คู่ที่ทำงานใน OpenSwan เช่น phase2alg=aes_gcm กับ ike=aes256-sha1;modp1024 ต้องแปลเป็นรูปแบบ esp= และ ike= ของ strongSwan และชื่ออัลกอริทึมก็แตกต่างกัน เนื่องจาก GCM ตรวจสอบความถูกต้องขณะเข้ารหัส จึงไม่ต้องมีทรานส์ฟอร์มความสมบูรณ์แยก ต่างจากชุด CBC ที่จับคู่กับ SHA บรรทัดเฟส 2 ที่คัดลอกจากการทำงานหนึ่งไปอีกอันโดยไม่แปลจะสร้างการปฏิเสธที่อ่านได้เหมือนตัวเลือกไม่ตรงกัน

ตรวจสอบความเชื่อมโยงลูก ไม่ใช่ตัวบ่งชี้อุโมงค์

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

ipsec statusall

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

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

เมื่อยังล้มเหลวหลังจากตัวเลือกตรงกัน

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

บันทึกแพ็กเก็ตขาเข้าและขาออกฝั่งละหนึ่งแพ็กเก็ตก่อนเปลี่ยนข้อเสนออื่น

ในตั๋ว ให้บันทึกตัวเลือก ข้อเสนอเฟส 1 และเฟส 2 และที่อยู่ต้นทาง ไว้ ค่าสี่ค่านี้อธิบายความล้มเหลว site-to-site ส่วนใหญ่ได้โดยไม่ต้องโทร