strongSwan บน EC2: ให้ VPC กำหนดเส้นทางของภาระงาน

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

เขียนที่อยู่ทั้งสี่ก่อน

ทุกขั้นตอนด้านล่างอ้างถึงที่อยู่เหล่านี้ ดังนั้นกรอกให้ครบสำหรับบัญชีของคุณก่อนแตะตารางเส้นทาง

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

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

ขั้นตอนที่ 1: ให้เส้นทางแก่ซับเน็ตของภาระงาน

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

แนวทางกำหนดเส้นทางผ่านอุปกรณ์ของ AWS อธิบายเป้าหมายชนิดอินเทอร์เฟซเครือข่ายและข้อกำหนดการตรวจสอบต้นทาง/ปลายทางของอินสแตนซ์ที่ส่งต่อ จำกัดการเปลี่ยนการตรวจสอบนั้นไว้ที่บทบาทเกตเวย์ และปล่อยอินสแตนซ์แอปพลิเคชันทั่วไปไว้ตามเดิม

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

ขั้นตอนที่ 2: เปิดการส่งต่อบนเกสต์

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

กลุ่มความปลอดภัยคือจุดที่ขั้นตอนนี้มักติดขัด อุปกรณ์กลางไม่สืบทอดพฤติกรรมการอ้างอิงกลุ่มความปลอดภัยของการสื่อสารระหว่างอินสแตนซ์โดยตรง ดังนั้นกฎที่คัดลอกจากตัวอย่าง Client VPN แบบจัดการอาจไม่ตรงเลยก็ได้ ตรวจกลุ่มความปลอดภัยและ ACL ของซับเน็ตบนเส้นทางจริงทั้งสองทิศทาง

ขั้นตอนที่ 3: ขยายซีเล็กเตอร์ไปยังต้นทางจริง

นโยบายที่ครอบคลุมเพียง 10.60.1.10/32 ทางฝั่ง AWS อธิบายความสำเร็จที่เริ่มจากเกตเวย์โดยไม่ครอบคลุม 10.60.2.20 เส้นทางไปยังปลายทางไกลไม่ได้ขยายซีเล็กเตอร์ของทราฟฟิก และนั่นคือครึ่งหลังของความประหลาดใจเดียวกัน

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

ถ้าการออกแบบที่ตกลงกันปกป้อง VPC ทั้งหมด ทั้งสองฝ่ายต้องยอมรับ 10.60.0.0/16 และ 10.90.0.0/24 ถ้าปกป้องเพียงภาระงานเดียว ให้ใช้พรีฟิกซ์ที่แคบกว่านั้นอย่างตั้งใจ ไม่ว่ากรณีใด ให้ตรวจนโยบาย CHILD-SA ที่ติดตั้งไว้ เพราะการตั้งค่าที่คุณแก้ไขกับฝ่ายที่ทำให้แคบลงต่างกันไม่ใช่ข้อตกลงเดียวกัน

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

ขั้นตอนที่ 4: ตรวจสอบ แล้วย้อนกลับหากจำเป็น

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

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

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