AWS Client VPN หรือ Site-to-Site: ตรวจสอบว่าใครเป็นผู้เปิดการเชื่อมต่อ
Client VPN ยืนยันตัวตนอุปกรณ์หรือผู้ใช้ ส่วน Site-to-Site เชื่อมเกตเวย์เข้ากับ AWS การตรวจสอบสี่ข้อตัดสินว่าอันไหนที่แล็ปท็อปหรือสาขาของคุณต้องการจริง
การตรวจสอบสี่ข้อตัดสินเรื่องนี้ และไม่มีข้อใดเป็นชื่อโปรโตคอล ใครเป็นผู้เปิดการเชื่อมต่อ AWS ยืนยันอะไร การเชื่อมต่อผูกกับเครือข่ายของคุณอย่างไร และมีการกำหนดเส้นทางกับนโยบายอะไรตามมา ตอบคำถามเหล่านี้ตามลำดับ แล้วการเลือกผลิตภัณฑ์มักจะเกิดขึ้นเอง ตอบหลังจากที่คุณซื้อการออกแบบไปแล้ว และคุณจะต้องปกป้องอุโมงค์ที่แก้ปัญหาผิดครึ่ง ไม่มีข้อใดในสี่ข้อ ขอให้คุณเลือกไซเฟอร์ นั่นคือเหตุผลที่การออกแบบที่เริ่มจากโปรโตคอลมักเป็นสัญญาณว่าข้อกำหนดไม่เคยถูกเขียนไว้
ทำการตรวจสอบแต่ละข้อกับจุดปลาย ไคลเอนต์ และตระกูลที่อยู่ที่คุณวางแผนจะใช้จริง ไม่ใช่กับหมวดหมู่ ผลิตภัณฑ์ VPN แบบจัดการมีความแตกต่างจากบล็อกก่อสร้าง OpenVPN และ IPsec ที่ดูคล้ายกัน
ข้อแรก ใครเป็นผู้เปิดการเชื่อมต่อ
หากสิ่งที่ต้องการเข้าถึงคือแล็ปท็อป โทรศัพท์ หรือเวิร์กสเตชันของผู้ดูแลระบบคนเดียว การเชื่อมต่อเริ่มที่อุปกรณ์ระยะไกล และการออกแบบคือการเข้าถึงไคลเอนต์ระยะไกล หากสิ่งที่ต้องการเข้าถึงคือสาขาที่เต็มไปด้วยเครื่องอยู่หลังเราเตอร์ตัวเดียว การเชื่อมต่อเริ่มที่เราเตอร์นั้น และการออกแบบคือเกตเวย์ถึงเกตเวย์ นี่คือการตรวจสอบที่ตัดสินกรณีส่วนใหญ่ และเป็นข้อที่ผู้คนข้ามไปเมื่อสไลด์ของผู้ขายได้วางกรอบการสนทนาไว้รอบไซเฟอร์แล้ว
หยุดตรงนี้หากคุณไม่สามารถระบุองค์ประกอบที่เริ่มการเชื่อมต่อได้ การออกแบบที่พยายามรองรับทั้งสองกรณีด้วยอุโมงค์เดียวมักจบลงด้วยเซสชันไคลเอนต์ที่แสร้งว่าเป็นเกตเวย์
ข้อที่สอง AWS ยืนยันอะไร
ใน Client VPN นั้น AWS ยืนยันตัวตนไคลเอนต์หรือผู้ใช้ที่กำหนดค่าไว้ ไม่ว่าจะเป็นใบรับรอง ไดเรกทอรี หรือตัวตนแบบเฟเดอเรต ขึ้นอยู่กับการตั้งค่า ใน Site-to-Site VPN นั้น AWS ยืนยันตัวตนของคู่เกตเวย์ ความแตกต่างนี้ไม่ใช่เรื่องผิวเผิน โมเดลหนึ่งขยายขนาดได้ด้วยการเพิ่มผู้ใช้และเพิกถอนข้อมูลรับรองของพวกเขา อีกโมเดลขยายขนาดได้ด้วยการไว้วางใจทุกสิ่งที่อยู่หลังเกตเวย์เดียว
การยืนยันเกตเวย์ไม่ได้ยืนยันพนักงานหรือแอปพลิเคชันทุกตัวที่อยู่ข้างหลัง ดังนั้นจึงควรรักษาตัวตนของแอปพลิเคชันและการเข้าถึงระดับทรัพยากรไว้ แม้เมื่ออุโมงค์เองเป็นที่ไว้วางใจ สาขาที่เราเตอร์มีตัวตนคู่ที่ถูกต้องไม่ควรถูกอ่านโดยอัตโนมัติราวกับว่าทุกโต๊ะในอาคารนั้นได้รับอนุญาต
ข้อที่สาม การเชื่อมต่อผูกอย่างไร
Client VPN ผูกผ่านการเชื่อมโยงซับเน็ตของ VPC หรือการเชื่อมต่อ Transit Gateway โดยตรงที่รองรับ Site-to-Site VPN ผูกกับเป้าหมาย AWS VPN ซึ่งมักเป็นเกตเวย์ส่วนตัวเสมือนหรือ Transit Gateway คู่มือสถาปัตยกรรม Client VPN อธิบายตัวเลือก Transit Gateway และการมีอยู่ของมันไม่ได้เปลี่ยนเซสชันแล็ปท็อปให้เป็นเกตเวย์สาขา หรือลบการยืนยันตัวตนและการอนุญาตของไคลเอนต์ที่อธิบายไว้ข้างต้น
ตรวจสอบการเชื่อมต่อที่บัญชีและภูมิภาคของคุณรองรับจริงก่อนที่จะออกแบบเส้นทางรอบๆ แล้วตรวจสอบว่าใครเป็นเจ้าของการเชื่อมต่อนั้น ตัวเลือกที่มีอยู่ในเอกสารแต่อยู่บนเครือข่ายที่คุณกำหนดค่าไม่ได้ไม่ใช่ตัวเลือก
ข้อที่สี่ มีการกำหนดเส้นทางและนโยบายอะไรตามมา
Client VPN นำการจัดการการเชื่อมต่อไคลเอนต์และกฎการอนุญาตสำหรับเครือข่ายปลายทางที่คุณอนุญาต ผู้ใช้ที่เชื่อมต่อยังต้องการเส้นทางไปยังจุดปลายที่ตั้งใจไว้ กฎการอนุญาตที่อนุญาตเส้นทางนั้น และการเข้าถึงใดๆ ที่ทรัพยากรเองต้องการ Site-to-Site VPN กำหนดเส้นทางระหว่างเครือข่ายที่แสดงโดยเกตเวย์ลูกค้า โดยใช้เส้นทางแบบคงที่ที่รองรับหรือ BGP ขึ้นอยู่กับการออกแบบ ดังนั้นเครื่องแต่ละเครื่องที่อยู่หลังเราเตอร์สาขาจึงไม่จำเป็นต้องเข้าสู่ระบบไคลเอนต์แยกกัน
อย่าสรุปพฤติกรรมที่ไม่รองรับจากหมวดหมู่ไปในทิศทางใดๆ VPN สำหรับการเข้าถึงระยะไกลไม่ได้ไร้ความสามารถโดยทั่วไปในการรับส่งข้อมูลขากลับหรือรองรับการจัดวางเกตเวย์ และ IPsec ไม่ได้ถูกบล็อกโดย NAT โดยอัตโนมัติ AWS อธิบายการผ่าน NAT และข้อกำหนดเกตเวย์ลูกค้า และข้อจำกัดที่แท้จริงคือการกำหนดค่าเกตเวย์ที่รองรับ ตรวจสอบข้อจำกัดของจุดปลายของคุณก่อนที่คุณจะกำหนดให้มีการเชื่อมต่อที่เริ่มไปยังไคลเอนต์ หรือส่งต่อ LAN ที่อยู่หลังเซสชันเดียว ความระมัดระวังเดียวกันใช้กับตระกูลที่อยู่ จุดปลายที่ทำงานบน IPv4 ไม่ได้หมายถึงเส้นทาง IPv6 ดังนั้นจงยืนยันตระกูลที่ไคลเอนต์หรือเกตเวย์ของคุณจะเจรจาจริง
Site-to-Site VPN ให้อุโมงค์สองอุโมงค์ต่อการเชื่อมต่อ และความซ้ำซ้อนนั้นเป็นงานออกแบบไม่ใช่คุณสมบัติที่คุณจะถือว่าเป็นจริงได้ การทำงานของเกตเวย์ลูกค้า การสลับเส้นทางเมื่อล้มเหลว และความครอบคลุมของการทดสอบทั้งหมดต้องได้รับการวางแผน การเปรียบเทียบเซสชันแล็ปท็อปหนึ่งเซสชันกับเซิร์ฟเวอร์ VPN แบบนามธรรมไม่ได้พิสูจน์อะไรเกี่ยวกับทั้งสอง
จุดที่การออกแบบทั้งสองมาบรรจบกัน
บริการทั้งสองไม่ได้แยกจากกัน และรูปแบบการผลิตทั่วไปใช้ทั้งคู่ พนักงานบน Client VPN เครือข่ายสาขาบน Site-to-Site พร้อมเส้นทางที่ชัดเจนและนโยบายการเข้าถึงระหว่างปลายทางที่ต้องสื่อสารกัน ตารางคือสรุปของการตรวจสอบสี่ข้อ ไม่ใช่สิ่งทดแทนการทำตามนั้น
| Question | AWS Client VPN | AWS Site-to-Site VPN |
|---|---|---|
| Who establishes it? | A client on a remote device | A customer gateway device or appliance |
| What is authenticated? | The client or user identity | The gateway peer identity |
| How does it attach? | VPC subnet association or Transit Gateway | Virtual private gateway or Transit Gateway |
| What carries the path? | An OpenVPN-based client tunnel | IPsec tunnels to AWS endpoints |
สิ่งหนึ่งที่ไม่มีผลิตภัณฑ์ใดในสองตัวแทนได้ คือ TLS ไปยังแอปพลิเคชันที่ข้อกำหนดการเข้ารหัสเลยจุดปลายของ VPN ออกไป หากขอบเขตการปฏิบัติตามข้อกำหนดของคุณสิ้นสุดที่แอปพลิเคชัน อุโมงค์คือการขนส่ง และใบรับรองยังคงเป็นการควบคุม
เขียนคำตอบทั้งสี่ข้อก่อนการทบทวนการออกแบบ ข้อละหนึ่งบรรทัด เมื่อสองข้อขัดแย้งกัน เช่น การออกแบบไคลเอนต์ที่ยืนยันด้วยผู้ใช้พร้อมข้อกำหนดการกำหนดเส้นทางขนาดสาขา ความขัดแย้งนั้นคือสิ่งที่ค้นพบ และการเห็นมันตอนนี้ถูกกว่าการเห็นระหว่างการเปลี่ยนผ่าน