AWS Client VPN หรือ VPN บน EC2: คู่มือปฏิบัติการ
ห้าขั้นตอนในการเลือกระหว่าง AWS Client VPN กับ VPN ที่โฮสต์เองบน EC2 พร้อมการตรวจสอบผ่าน CLI การแบ่งความรับผิดชอบ การย้ายระบบ และการย้อนกลับ
ทั้งสองทางเลือกมอบ VPN สำหรับการเข้าถึงระยะไกลให้ทีมของคุณ คำถามที่น่าสนใจจึงไม่ใช่ว่าอันไหนมีอยู่ แต่คืออันไหนที่คุณดูแลได้ ความแตกต่างอยู่ที่ว่าใครเป็นเจ้าของปลายทางตอนตี 3 และคุณเข้าถึงการควบคุมใดได้เมื่อมีบางอย่างพัง ทำตามห้าขั้นตอนด้านล่างตามลำดับ เพราะแต่ละขั้นอาจยุติการเปรียบเทียบได้ก่อนเวลา การข้ามขั้นตอนสำรวจสินทรัพย์คือสาเหตุที่ทีมต้องย้ายระบบสองครั้ง
ขั้นที่ 1: เขียนความต้องการก่อนบิล
คุณต้องมีข้อเท็จจริงห้าข้อในหน้าเดียว: ใครพิสูจน์ตัวตนกับอะไร แพลตฟอร์มไคลเอนต์ใดต้องใช้งานได้ ปลายทางส่วนตัวใดเข้าถึงได้ คุณสัญญาเรื่องความพร้อมใช้งานไว้อย่างไร และทราฟฟิกเป็นอย่างไรจริง ๆ หากไม่มีสิ่งเหล่านี้ การเปรียบเทียบในภายหลังจะกลายเป็นการโต้เถียงเรื่องรายการฟีเจอร์
จงเจาะจงเรื่องปลายทาง «การเข้าถึง VPC» มักหมายถึงสามสิ่งต่างกัน: CIDR ของ VPC เครือข่ายที่เชื่อม peer และช่วงออนพรีมิสหลัง Transit Gateway ปลายทางแบบจัดการเข้าถึงได้ทั้งสาม แต่แต่ละอย่างต้องมีเส้นทางและกฎการอนุญาต และแต่ละอย่างเป็นบรรทัดแยกในความต้องการของคุณ
ขั้นที่ 2: ระบุสิ่งที่ทำงานอยู่แล้ว
ก่อนออกแบบสิ่งใด ให้ระบุปลายทางที่มีอยู่และเซิร์ฟเวอร์ใด ๆ ที่โฮสต์บน EC2 พร้อมกลุ่มความปลอดภัย การเรียกเหล่านี้เป็นการอ่านเท่านั้นและปลอดภัยที่จะรันจากบัญชีที่มีสิทธิ์ describe
aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpnอ่านผลลัพธ์เป็นแผนที่ของสิ่งที่ไคลเอนต์เข้าถึงได้แล้ว กฎการอนุญาตที่หายไปอธิบายความล้มเหลวที่ดูเหมือนปัญหาเส้นทาง และปลายทางที่เชื่อมกับซับเน็ตเดียวอธิบายว่าทำไมความล้มเหลวของโซนจึงทำให้บริการทั้งหมดล่ม
บันทึกกลุ่มความปลอดภัยที่แนบกับอินสแตนซ์ที่โฮสต์เองด้วย กฎเหล่านั้นเป็นส่วนหนึ่งของโมเดลการเข้าถึง และเป็นสิ่งแรกที่แตกหักอย่างเงียบ ๆ เมื่อมีคนสร้างอินสแตนซ์ใหม่จากเทมเพลต
ขั้นที่ 3: แบ่งความรับผิดชอบ
บริการแบบจัดการเป็นเจ้าของกลุ่มปลายทาง การแพตช์ และความพร้อมใช้งานในภูมิภาค คุณเป็นเจ้าของการลงทะเบียนตัวตน กฎการอนุญาต เส้นทางเครือข่ายหลังปลายทาง การตั้งค่าบันทึก และการตัดสินใจว่าจะเชื่อมซับเน็ตกี่ตัว
การโฮสต์เองกลับกัน คุณเป็นเจ้าของระบบปฏิบัติการเกสต์ เดมอน VPN และการตั้งค่า ใบรับรองและคีย์ สำรองข้อมูล การตรวจสอบ และการกู้คืน โมเดลความปลอดภัยของ EC2 วางความปลอดภัยของเกสต์และแอปพลิเคชันไว้ที่ลูกค้า และเซิร์ฟเวอร์ VPN ก็เป็นเกสต์เหมือนเกสต์อื่น
เขียนการแบ่งเป็นตารางที่มีชื่อในคอลัมน์ขวา หากไม่มีชื่อใครอยู่ข้างการต่ออายุใบรับรอง นั่นคือข้อค้นพบ และสำคัญกว่าส่วนต่างค่าใช้จ่ายต่อชั่วโมง
ขั้นที่ 4: เปรียบเทียบกับภาระงานที่คุณอธิบายได้
ต้นทุนเป็นไปตามรูปร่าง ไม่ใช่ขนาด สำหรับตัวเลือกแบบจัดการ ให้นับชั่วโมงการเชื่อมปลายทาง ชั่วโมงการเชื่อมต่อของไคลเอนต์ การรับส่งข้อมูล และบริการตัวตนและบันทึกที่คุณเปิดใช้ สำหรับการโฮสต์เอง ให้นับการประมวลผล พื้นที่จัดเก็บ เครือข่าย สิทธิ์การใช้งาน และเวลาวิศวกรรมที่ทำให้เซิร์ฟเวอร์ได้รับการแพตช์ ใส่ตัวเลขทั้งสองชุดในแผ่นเดียวกันด้วยกรอบเวลาเดียวกัน การเปรียบเทียบสามปีที่เพิกเฉยต่อชั่วโมงแพตช์จะเอื้อเซิร์ฟเวอร์ที่คุณมีอยู่แล้วเสมอ
การเปรียบเทียบประสิทธิภาพต้องมีวินัยแบบเดียวกัน หนึ่งเซสชันเดสก์ท็อปแบบโต้ตอบ หนึ่งการถ่ายโอนขนาดใหญ่ และห้าสิบคำขอเล็กพร้อมกันกดดันส่วนต่าง ๆ ของเส้นทาง: CPU สำหรับการเข้ารหัส ความสามารถเครือข่ายของอินสแตนซ์ สแต็กของไคลเอนต์เอง และปลายทาง ทดสอบด้วยไคลเอนต์ที่เป็นตัวแทนและงานเดียวกันในการออกแบบทั้งสอง
อินสแตนซ์ที่ใหญ่ขึ้นไม่ใช่หลักฐานว่าการถ่ายโอนจะเร็วขึ้น และหนึ่งเซสชันที่สำเร็จไม่ใช่แผนความจุ มองคำเล่าลือที่สืบทอดมาเกี่ยวกับตระกูลอินสแตนซ์เป็นสมมติฐานที่ต้องทดสอบ ไม่ใช่กฎการซื้อ
ขั้นที่ 5: ย้ายระบบด้วยการย้อนกลับที่คุณเคยรันแล้ว
รันปลายทางทั้งสองแบบขนานกันตามระยะเวลาที่กำหนด แจกจ่ายโปรไฟล์ไคลเอนต์ใหม่ให้กลุ่มเล็กก่อน และอย่าแตะกฎการอนุญาตของปลายทางเดิมจนกว่ากลุ่มจะใช้ตัวใหม่ในงานจริง การย้อนกลับคือการสลับโปรไฟล์ ไม่ใช่การสร้างใหม่ ดังนั้นตัดสินใจตอนนี้ว่าโปรไฟล์เดิมอยู่ที่ไหน
ตรวจสอบตามลำดับนี้: การพิสูจน์ตัวตนสำเร็จ ไคลเอนต์ได้รับเส้นทางที่คาดไว้ ปลายทางที่ได้รับอนุญาตตอบสนอง และปลายทางที่ไม่ได้รับอนุญาตล้มเหลว และบันทึกแสดงทั้งสองเหตุการณ์ หากขั้นตอนใดล้มเหลว ให้หยุดและแก้ขั้นตอนนั้นแทนที่จะไปยังกลุ่มไคลเอนต์ถัดไป บันทึกผลของการตรวจแต่ละครั้ง เพราะการย้ายระบบที่จำได้เพียงว่า «มันได้ผล» ไม่สามารถดีบักได้ในอีกหนึ่งเดือน
หลังการย้ายระบบ ให้กำหนดการตรวจที่น่าเบื่อ: การหมดอายุใบรับรอง จำนวนการเชื่อม กฎการอนุญาตที่ไม่ตรงกับกลุ่มอีกต่อไป และจำนวนการเชื่อมต่อเทียบกับความคาดหวังของคุณ คู่มือการดูแล Client VPN เป็นเอกสารอ้างอิงสำหรับส่วนปลายทาง การพิสูจน์ตัวตน และการกำหนดเส้นทางที่คุณตั้งค่าไว้