VGW หรือ TGW? อุโมงค์ IPsec ของ AWS Site-to-Site สิ้นสุดที่ใด

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

ระบุจุดปลายทั้งสามก่อนประเมินสิ่งใด

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

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

การตรวจสอบ 1: เกตเวย์ใดสิ้นสุดอุโมงค์จริง

ทั้งสองโครงสร้างได้รับการสนับสนุน และ คู่มือสถาปัตยกรรม Site-to-Site VPN อธิบายทั้งสองเคียงข้างกัน ดังนั้นถาม API แทนที่จะถามแผนภาพที่มักมีอายุหนึ่งปี คำค้นแบบอ่านอย่างเดียวบนการเชื่อมต่อหนึ่งรายการจะคืนฟิลด์เป้าหมาย VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

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

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

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

การตรวจสอบ 2: แพ็กเก็ตภายในยังขนส่งอะไร

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

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

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

การตรวจสอบ 3: อะไรสิ้นสุด TLS หลังเกตเวย์

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

ทดสอบจุดปลายที่คุณใส่ใจจริงจากภายใน VPC ด้วยชื่อที่แอปพลิเคชันใช้ ไม่ใช่ด้วย IP ที่คุณเคยแก้ไขครั้งเดียว:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

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

บันทึกผลลัพธ์เป็นส่วน ไม่ใช่เป็นคำตัดสิน

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

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

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