AWS Client VPN เชื่อมต่อแล้ว แต่ EC2 ยังไม่ตอบสนอง
เชื่อมต่อแล้วหมายถึงเพียงใบรับรองหรือการเข้าสู่ระบบ SAML ทำงานเท่านั้น กฎการอนุญาต เส้นทาง endpoint และกลุ่มความปลอดภัยต่างเฝ้าดูเส้นทางคนละช่วงไปยังโฮสต์ส่วนตัว
แล็ปท็อปของผมแสดงว่าเชื่อมต่อแล้ว ไคลเอนต์ AWS Client VPN แสดงสถานะสีเขียว endpoint บันทึกเซสชัน และถึงอย่างนั้นผมก็ยังเปิดพอร์ต MongoDB บนอินสแตนซ์ EC2 ในซับเน็ตส่วนตัวไม่ได้ ไม่มีอะไรเสียอย่างชัดเจน: ใบรับรองใช้ได้ โปรไฟล์มาจากคอนโซล และอุโมงค์รับส่งทราฟฟิกอยู่ ข้อผิดพลาดเป็นของผม เพราะผมอ่านคำว่าเชื่อมต่อแล้วว่าได้รับอนุญาต
การเข้าสู่ระบบตอบคำถามเพียงข้อเดียว: ตัวตนนี้สร้างเซสชันได้หรือไม่ ทุกอย่างหลังจากนั้นตัดสินด้วยกฎแยกต่างหากที่ไม่เคยเห็นใบรับรองของคุณ เซสชันที่ผ่านการยืนยันตัวตนกับแพ็กเก็ตที่มาถึงคือความสำเร็จสองอย่างที่ต่างกัน และช่องว่างระหว่างสองสิ่งนี้คือที่อยู่ของรายงานส่วนใหญ่ว่า VPN ขึ้นแล้วแต่โฮสต์เข้าถึงไม่ได้
การตรวจสอบด้านล่างคือลำดับที่ผมใช้อยู่ตอนนี้
เซสชันที่เชื่อมต่อแล้วพิสูจน์อะไรได้จริง
ระหว่างแฮนด์เชก endpoint จะตรวจสอบใบรับรองไคลเอนต์กับทรัสต์สโตร์ของตน หรือเปลี่ยนเส้นทางเบราว์เซอร์ไปยังผู้ให้บริการตัวตนของคุณเมื่อมีการตั้งค่า SAML ถ้าผ่าน ไคลเอนต์จะได้รับที่อยู่จาก CIDR ของไคลเอนต์ของ endpoint และคอนโซลแสดงการเชื่อมต่อที่ใช้งานอยู่ ไม่มีจุดใดในการแลกเปลี่ยนนั้นที่ถามว่าคุณเข้าถึง 10.0.4.17 บนพอร์ต 27017 ได้หรือไม่
การอนุญาตสำหรับปลายทางเป็นอ็อบเจกต์แยกต่างหากบน endpoint ทุกโฟลว์จะถูกเทียบกับกฎการอนุญาต และแต่ละกฎจับคู่ CIDR ปลายทางกับกลุ่มที่กฎนั้นมอบให้ เมื่อไม่มีกฎใดครอบคลุมปลายทาง endpoint จะยอมรับเซสชันและทิ้งทราฟฟิก ไม่มีแบนเนอร์ ไม่มีลูปเชื่อมต่อใหม่ และไม่มีสิ่งใดในอินเทอร์เฟซไคลเอนต์ที่บอกว่าถูกปฏิเสธ
เปรียบเทียบกฎการอนุญาตกับทรัพยากร ไม่ใช่กับ VPC
แสดงรายการกฎและวางไว้ข้างที่อยู่ที่อินสแตนซ์มีจริง:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8เอาต์พุตแสดง CIDR ปลายทางและ ID กลุ่มต่อกฎ มีความล้มเหลวสองอย่างซ่อนอยู่ ข้างใน กฎอาจอนุญาต 10.0.0.0/16 ขณะที่อินสแตนซ์อยู่ใน VPC ที่เพียร์ไว้บน 10.1.0.0/16 เส้นทางเพียริงมีอยู่ แต่ไม่มีใครเขียนกฎการอนุญาตสำหรับช่วงที่สอง หรือกฎชี้ไปยังกลุ่มไดเรกทอรีที่ผู้ใช้เป็นสมาชิกในไดเรกทอรี แต่ไม่ใช่ในกลุ่มที่ endpoint ประเมิน
เขียนกฎที่แคบที่สุดซึ่งครอบคลุมปลายทาง และเพิ่มกฎที่สองเฉพาะเมื่อจำเป็นต้องใช้ CIDR ที่สองจริง ๆ กฎกว้าง 0.0.0.0/0 จากควิกสตาร์ทนั้นใช้ได้ และนั่นคือเหตุผลที่มันอยู่รอดถึงโปรดักชันและซ่อนโมเดลไว้
ตารางเส้นทางสองตารางตัดสินว่าแพ็กเก็ตจะเคลื่อนที่หรือไม่
เส้นทาง endpoint จับคู่ CIDR ปลายทางกับหนึ่งในซับเน็ตที่ endpoint เชื่อมโยงอยู่ นั่นคือครึ่งหนึ่งของเส้นทาง ตารางเส้นทางของซับเน็ตเองยังต้องรู้วิธีส่งต่อแพ็กเก็ต และนั่นสำคัญในจังหวะที่ปลายทางอยู่หลังการเชื่อมต่อเพียริง ทรานซิตเกตเวย์ หรือช่วงภายในองค์กรที่เข้าถึงได้ผ่านอุโมงค์ไซต์ทูไซต์
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8มองหาเส้นทางที่ปลายทางตรงกับ CIDR ของทรัพยากรและเป้าหมายเป็นซับเน็ตที่เชื่อมโยงอยู่ ถ้าไม่มีเส้นทาง ให้เพิ่ม ถ้ามีและโฮสต์ยังเงียบ ช่องว่างอยู่ฝั่ง VPC จึงให้เทียบกับตารางเส้นทางของซับเน็ตที่เชื่อมโยง
การตั้งค่าฝั่งไคลเอนต์อย่างหนึ่งทำให้การกำหนดเส้นทางพังโดยที่อุโมงค์ไม่พัง: โปรไฟล์ที่มี route-nopull คำสั่งนั้นบอกไคลเอนต์ที่อิง OpenVPN ให้เพิกเฉยต่อเส้นทางที่เซิร์ฟเวอร์ดันมา ดังนั้นอินเทอร์เฟซจะขึ้นมาด้วยที่อยู่ของ endpoint เท่านั้น และปลายทางก็ไม่มีเส้นทางเลย ตรวจสอบด้วย ip route show บน Linux หรือ netstat -rn บน macOS ว่ามีเส้นทางผ่านอินเทอร์เฟซ tun หรือไม่ ถ้าไม่มี ให้เอา route-nopull ออกจากโปรไฟล์ที่ส่งออกแล้วเชื่อมต่อใหม่เพื่อให้เส้นทางที่ถูกดันมาถูกนำไปใช้
กลุ่มความปลอดภัยไม่เห็นที่อยู่ไคลเอนต์ของคุณ
นี่คือส่วนที่ผมเข้าใจผิดมาครึ่งวัน สำหรับ endpoint IPv4 ที่เชื่อมโยงกับซับเน็ต บริการจะแปลที่อยู่ต้นทางของไคลเอนต์เป็นที่อยู่ของอินเทอร์เฟซเครือข่ายของ endpoint ในซับเน็ตนั้น แพ็กเก็ตที่มาถึงอินสแตนซ์ไม่ได้พาที่อยู่ที่ไคลเอนต์ของคุณแสดงไว้ ดังนั้นกฎกลุ่มความปลอดภัยที่อนุญาตพูลไคลเอนต์ เช่น 172.16.0.0/22 จึงไม่ตรงกับสิ่งใดเลย
อนุญาตพอร์ตจากกลุ่มความปลอดภัยของ endpoint ซึ่งผูกกับอินเทอร์เฟซของการเชื่อมโยง ไม่ใช่จาก CIDR ของไคลเอนต์ การอ้างถึงกลุ่มนั้นคงทนกว่าการเขียนที่อยู่แบบตายตัว เพราะที่อยู่ของอินเทอร์เฟซไม่ใช่ของคุณที่จะควบคุม เน็ตเวิร์ก ACL ไม่เก็บสถานะ ดังนั้นที่ใดมีรายการกำหนดเอง ทั้งทิศทางเข้าและทิศทางออกต้องอนุญาตโฟลว์
เชื่อมต่อกับที่อยู่ส่วนตัวของอินสแตนซ์ด้วย IP สาธารณะนำแพ็กเก็ตออกนอก VPC แล้วนำกลับเข้ามาทางอื่นด้วยกฎอื่น การทดสอบผ่านที่อยู่สาธารณะจึงไม่บอกอะไรเกี่ยวกับเส้นทางส่วนตัว
ลำดับการแยกปัญหาที่หยุดเมื่อเจอความล้มเหลวแรก
ไล่ตามลำดับและหยุดตรงที่ข้อหนึ่งล้มเหลว แต่ละขั้นตัดหนึ่งชั้นออก ไม่ใช่ทั้งหมด
- ยืนยันว่าเซสชันใช้ตัวตนใดและ endpoint ประเมินกลุ่มใด ใบรับรองจากทรัสต์สโตร์หนึ่งไม่ใช่ตัวตนเดียวกันกับข้อความยืนยัน SAML จากไดเรกทอรี
- ยืนยันว่ากฎการอนุญาตครอบคลุม CIDR ของทรัพยากรสำหรับกลุ่มนั้น
- ยืนยันว่ามีเส้นทาง endpoint และชี้ไปยังซับเน็ตที่เชื่อมโยงอยู่ จากนั้นจึงยืนยันว่าตารางเส้นทางของซับเน็ตส่งต่อได้
- ยืนยันว่ากลุ่มความปลอดภัยอนุญาตพอร์ตจากอินเทอร์เฟซของ endpoint ไม่ใช่จากพูลไคลเอนต์
- ทดสอบจากภายใน VPC ด้วยเซสชัน SSM บนอินสแตนซ์อื่นในซับเน็ตเดียวกัน เพื่อแยกปัญหาของแอปพลิเคชันออกจากปัญหาของเส้นทางไคลเอนต์
เมื่อขั้นตอนไม่ชี้ขาด ตารางนี้คือสิ่งที่ผมใช้ยึด:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
รายละเอียดบัญชีสองอย่างสร้างอาการที่ดูเหมือนการล้มเหลวของสิทธิ์ ผู้ใช้แต่ละคนต้องมีใบรับรองไคลเอนต์แยกกัน การใช้ใบเดียวร่วมกันระหว่างสองเครื่องทำให้เซสชันผลักกันเอง และผลลัพธ์คือลูปเชื่อมต่อใหม่ ไม่ใช่การปฏิเสธ เมื่อสร้าง endpoint ใหม่ คอนโซลแสดงชื่อ DNS ที่ไคลเอนต์บางเวอร์ชันยอมรับเฉพาะเมื่อมีคำนำหน้าแบบสุ่มที่แสดงบนหน้า endpoint ดังนั้นคัดลอกชื่อเต็มแทนการสร้างขึ้นใหม่
ถ้าขั้นที่ห้าทำให้คุณติด ให้ดึงบันทึกการเชื่อมต่อของ endpoint และอ่านรายการอนุญาตก่อนจะเปลี่ยนสิ่งใด บันทึกจะระบุปลายทางที่ตรวจสอบและกฎที่ตรงหรือไม่ตรง ซึ่งย่อคำถามสี่ชั้นให้เหลือคำตอบเดียว