ทำไม EC2 จึงเข้าถึงแล็ปท็อป AWS Client VPN ของคุณไม่ได้
Client VPN แปลงต้นทาง IPv4 ของไคลเอนต์ไปยังอินเทอร์เฟซของปลายทาง ผลลัพธ์คือคำตอบทำงานได้ แต่การเชื่อมต่อใหม่จาก EC2 ไม่ได้
แล็ปท็อปที่เชื่อมต่อผ่าน AWS Client VPN เข้าถึงแอปพลิเคชันบน EC2 ได้โดยไม่มีปัญหา จากนั้นคุณลองทิศทางตรงกันข้าม จาก EC2 ไปยังที่อยู่ที่มอบให้ไคลเอนต์ และการเชื่อมต่อค้างหรือถูกปฏิเสธ ความไม่สมมาตรนี้แทบไม่เคยเป็นกฎของกลุ่มความปลอดภัยที่หายไป บนปลายทาง Client VPN ที่เชื่อมโยงกับซับเน็ตของ VPC นั้น AWS แปลงต้นทาง IPv4 ของไคลเอนต์ไปยังอินเทอร์เฟซเครือข่ายของปลายทาง ดังนั้นจึงไม่มีที่อยู่ VPC ขาเข้าที่เป็นตัวแทนแล็ปท็อปของคุณ
เริ่มจากสิ่งที่การดักจับแสดงให้เห็น
ดักจับแพ็กเก็ตบนโฮสต์ EC2 ขณะที่ไคลเอนต์เชื่อมต่อ แล้วอ่านที่อยู่ต้นทางที่แอปพลิเคชันเห็นจริง หากเป็นอินเทอร์เฟซของปลายทางฝั่ง VPC ไม่ใช่ที่อยู่จากพูลไคลเอนต์ การแปลงก็ได้รับการยืนยันก่อนที่คุณจะเปลี่ยนกฎแม้แต่ข้อเดียว
พูลไคลเอนต์คือช่วงการจัดสรร ไม่ใช่ซับเน็ตที่มีเส้นทางย้อนกลับ ความแตกต่างนี้คือจุดที่การตรวจสอบแบบนี้ส่วนใหญ่ผิดพลาด
การแปลงที่อธิบายความไม่สมมาตร
มีสามโฟลว์ที่ถูกสับสนกัน และมีเพียงโฟลว์เดียวเท่านั้นที่ผู้คนทดสอบ
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
คำอธิบายองค์ประกอบของ Client VPN ระบุชัดเจนว่าต้นทาง IPv4 ของไคลเอนต์ถูกแปลงไปยังอินเทอร์เฟซของปลายทาง ซึ่งเพียงพอที่จะเห็นว่าทำไมแถวกลางจึงไม่มีอะไรให้จับคู่
การเชื่อมต่อใหม่ต้องมีเส้นทาง ขั้นตอนการแปลงที่อยู่ และการตัดสินใจอนุญาต สถานะการแปลงจากเซสชันของคนอื่นไม่ได้ให้ทั้งสามอย่างนั้น
ทำไมคำตอบจึงไม่ใช่การเชื่อมต่อใหม่
คำตอบ TCP ถูกจับคู่กับรายการที่มีอยู่แล้ว นั่นคือเหตุผลที่เส้นทางย้อนกลับทำงานได้โดยไม่มีกฎขาเข้าเลย SYN ใหม่จากโฮสต์ EC2 ไม่มีรายการให้จับคู่ จึงกลายเป็นความพยายามขาออกธรรมดาไปยังปลายทางที่ VPC ไม่รู้วิธีไปถึง
นี่ก็เป็นเหตุผลที่การอธิบายสิ่งนี้ว่าเป็นการรับส่งข้อมูลทางเดียวจึงทำให้เข้าใจผิด การรับส่งข้อมูลย้อนกลับไหลอย่างต่อเนื่องในเซสชันเหล่านี้ ส่วนที่ไม่มีเส้นทางคือการเริ่มต้น
อะไรยังคงทำให้เซสชันที่ควรทำงานล้มเหลว
กลุ่มความปลอดภัย ACL ของเครือข่าย และไฟร์วอลล์ของแล็ปท็อปเองล้วนสำคัญต่อการเชื่อมต่อที่ควรสำเร็จ ping ที่ล้มเหลวบอกได้น้อยที่สุด เพราะนโยบาย ICMP มักแยกจากนโยบาย TCP ที่คุณสนใจ
เขียนกฎเหล่านั้น โดยอิงต้นทางที่ถูกแปลง ไม่ใช่ที่อยู่ของไคลเอนต์ กฎที่ผูกกับที่อยู่ซึ่งไม่เคยปรากฏบนเครือข่ายคือความล้มเหลวที่เกิดจากตัวเองบ่อยที่สุดในการออกแบบนี้
เมื่อ VPC ต้องเริ่มบทสนทนาจริง ๆ
หากบริการต้องแจ้งสถานีงาน ให้กลับทิศทางและปล่อยให้ไคลเอนต์ถือช่องทางขาออกถาวรที่บริการตอบกลับ หากเครือข่ายระยะไกลทั้งหมดต้องเข้าถึงได้จาก VPC ให้เลือกสถาปัตยกรรมที่เผยแพร่คำนำหน้าและนโยบายการเข้าถึงของตน แทนที่จะถือว่า Client VPN ทำเช่นนั้นอยู่แล้ว การเข้าถึงระหว่างไคลเอนต์เป็นกรณีที่สามที่แคบกว่าและมีออบเจ็กต์เส้นทางและการอนุญาตของตัวเอง ไม่มีสิ่งใดในนี้เป็นเพียงกล่องกาเครื่องหมายบนปลายทางที่มีอยู่
รักษาขอบเขตของคำอธิบาย IPv4 ให้ซื่อสัตย์ด้วย เอกสาร AWS ปัจจุบันแยก IPv6 ซึ่งการแปลงนั้นไม่ถูกนำมาใช้ และรูปแบบการเชื่อมต่ออื่นที่กำหนดเส้นทางต่างออกไป
ทดสอบในสามขั้นตอนที่มีป้ายกำกับ ไคลเอนต์เปิดเซสชันที่ได้รับอนุญาต บริการใน VPC ตอบเซสชันนั้น และโฮสต์ใน VPC เปิดเซสชันใหม่ไปยังไคลเอนต์ การที่สองขั้นแรกสำเร็จแต่ขั้นที่สามล้มเหลวคือรูปแบบที่คาดไว้ของการออกแบบนี้ ไม่ใช่ข้อบกพร่องที่ต้องตามล่าด้วยกฎไฟร์วอลล์