Vì sao EC2 không thể tiếp cận laptop AWS Client VPN của bạn
Client VPN dịch nguồn IPv4 của máy khách sang giao diện mạng của điểm cuối. Vì thế phản hồi hoạt động còn kết nối mới từ EC2 thì không.
Một laptop kết nối qua AWS Client VPN tiếp cận ứng dụng trên EC2 mà không gặp trở ngại nào. Sau đó bạn thử chiều ngược lại, từ EC2 đến địa chỉ đã cấp cho máy khách, và kết nối bị treo hoặc bị từ chối. Sự bất đối xứng đó hiếm khi là một quy tắc nhóm bảo mật bị thiếu. Trên một điểm cuối Client VPN gắn với các mạng con VPC, AWS dịch nguồn IPv4 của máy khách sang giao diện mạng của điểm cuối, nên không có địa chỉ VPC đi vào nào đại diện cho laptop của bạn.
Bắt đầu từ những gì bản ghi cho thấy
Ghi lưu lượng trên máy chủ EC2 trong lúc máy khách kết nối và đọc địa chỉ nguồn mà ứng dụng thực sự thấy. Nếu đó là giao diện của điểm cuối phía VPC chứ không phải địa chỉ từ nhóm máy khách, việc dịch đã được xác nhận trước khi bạn thay đổi dù chỉ một quy tắc.
Nhóm máy khách là một dải cấp phát, không phải mạng con có tuyến trả về. Chính ở điểm khác biệt này mà phần lớn các cuộc điều tra như vậy đi sai hướng.
Phép dịch giải thích sự bất đối xứng
Ba luồng bị nhầm lẫn với nhau, và chỉ một trong số đó là luồng mà người ta kiểm tra.
| 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 |
Mô tả các thành phần của Client VPN nói rõ rằng nguồn IPv4 của máy khách được dịch sang giao diện của điểm cuối, và thế là đủ để thấy vì sao hàng giữa không có gì để khớp.
Một kết nối mới cần tuyến, bước phân giải địa chỉ và quyết định cấp quyền. Trạng thái dịch từ phiên của người khác không cung cấp bất kỳ điều nào trong ba thứ đó.
Vì sao phản hồi không phải kết nối mới
Phản hồi TCP được khớp với một mục đã có, đó là lý do đường về hoạt động mà không cần bất kỳ quy tắc đi vào nào. Một SYN mới từ máy chủ EC2 không có mục nào để khớp, nên nó trở thành một nỗ lực đi ra thông thường hướng tới đích mà VPC không biết cách tiếp cận.
Đó cũng là lý do mô tả điều này như lưu lượng chỉ đi một chiều là gây hiểu nhầm. Lưu lượng về vẫn chảy liên tục trong các phiên này. Phần không có đường đi là việc khởi tạo.
Điều gì vẫn phá hỏng một phiên lẽ ra phải hoạt động
Nhóm bảo mật, ACL mạng và tường lửa của chính laptop đều quan trọng với những kết nối lẽ ra phải thành công. Một ping thất bại cho biết ít nhất, vì chính sách ICMP thường tách khỏi chính sách TCP mà bạn quan tâm.
Hãy viết những quy tắc đó theo nguồn đã được dịch, không phải theo địa chỉ máy khách. Các quy tắc gắn với địa chỉ không bao giờ xuất hiện trên mạng là lỗi tự gây ra phổ biến nhất trong thiết kế này.
Khi VPC thực sự phải bắt đầu cuộc trò chuyện
Nếu một dịch vụ phải thông báo cho một máy trạm, hãy đảo chiều và để máy khách giữ một kênh đi ra thường trực mà dịch vụ trả lời trên đó. Nếu toàn bộ một mạng từ xa phải tiếp cận được từ VPC, hãy chọn một kiến trúc công bố các tiền tố và chính sách truy cập của nó thay vì giả định Client VPN đã làm việc đó. Truy cập máy khách-tới-máy khách là trường hợp thứ ba, hẹp hơn, với các đối tượng tuyến và cấp quyền riêng. Không điều nào trong số này chỉ là một ô đánh dấu trên điểm cuối hiện có.
Hãy giữ trung thực cả phạm vi của phần giải thích IPv4. Tài liệu AWS hiện tại tách IPv6, nơi phép dịch đó không được áp dụng, và các mô hình kết nối khác định tuyến theo cách khác.
Hãy thử theo ba bước có nhãn: máy khách mở một phiên được cho phép, dịch vụ trong VPC trả lời phiên đó, và một máy chủ trong VPC mở phiên mới về phía máy khách. Việc hai bước đầu thành công còn bước thứ ba thất bại chính là hình dạng mong đợi của thiết kế này, không phải lỗi cần đuổi theo bằng quy tắc tường lửa.