EC2 ข้ามโซนความพร้อมใช้งาน: ตรวจสอบเส้นทางก่อนใช้ VPN

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

การตรวจสอบ 1: VPC เดียวกันหรือต่างกัน

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

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

การตรวจสอบ 2: ตารางเส้นทางของซับเน็ตบอกอะไร

เขียนผังด้วยค่าจริง VPC ที่ 10.60.0.0/16 พร้อมซับเน็ต 10.60.1.0/24 และ 10.60.2.0/24 ให้เส้นทางแก่อินสแตนซ์ 10.60.1.10 และ 10.60.2.20 ผ่านเส้นทางภายในของ VPC

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

ใช้ที่อยู่และชื่อส่วนตัวที่ VPC กำหนดให้จริง ที่อยู่ส่วนตัวไม่จำเป็นต้องขึ้นต้นด้วย 10 และการคิดค้นขึ้นมาจากความจำคือวิธีที่ทำให้สภาพแวดล้อมที่ทำงานอยู่ถูกวินิจฉัยผิด

การตรวจสอบ 3: เส้นทางหรือการอนุญาต

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

เบื้องหลังนั้นคือไฟร์วอลล์ของ guest การผูก listener และตัวตนของแอปพลิเคชันเอง แต่ละอย่างสามารถปฏิเสธคำขอที่เส้นทางนำส่งอย่างสมบูรณ์ได้

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

การตรวจสอบ 4: จำเป็นต้องมีการเชื่อมต่อแยกจริงหรือไม่

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

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

การตรวจสอบ 5: คำถามเรื่องการเข้ารหัส

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

แยกข้อกล่าวอ้างเรื่องเลเยอร์เครือข่ายและเลเยอร์แอปพลิเคชันออกจากกันในบันทึกการออกแบบ เพราะการรวมเข้าด้วยกันคือวิธีที่การทบทวนลงเอยด้วยการอ้างการป้องกันที่ไม่มีใครนำไปใช้

สิ่งที่ต้องบันทึก

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

การวางในโซนเพียงอย่างเดียวไม่เคยบอกให้คุณเพิ่ม VPN และไม่เคยอธิบายว่าทำไมคำขอส่วนตัวจึงล้มเหลว