AWS Client VPN đã kết nối, nhưng EC2 vẫn không phản hồi

Laptop của tôi báo đã kết nối. Ứng dụng AWS Client VPN hiển thị trạng thái xanh, endpoint ghi nhận một phiên, và tôi vẫn không mở được cổng MongoDB trên một phiên bản EC2 trong subnet riêng. Không có gì hỏng rõ ràng: chứng chỉ hợp lệ, hồ sơ đến từ console và đường hầm vẫn chở lưu lượng. Lỗi là ở tôi, vì tôi đọc kết nối như đã được cấp quyền.

Đăng nhập trả lời đúng một câu hỏi: danh tính này có được lập phiên không? Mọi thứ sau đó do những quy tắc riêng quyết định, và chúng không bao giờ nhìn thấy chứng chỉ của bạn. Một phiên đã xác thực và một gói tin đến nơi là hai thành công khác nhau, và khoảng trống giữa chúng là nơi cư trú của phần lớn báo cáo kiểu VPN đã bật nhưng không tới được máy chủ.

Các bước kiểm tra dưới đây là thứ tự tôi dùng hiện nay.

Một phiên đã kết nối thực sự chứng minh điều gì

Trong handshake, endpoint xác thực chứng chỉ ứng dụng với trust store của nó, hoặc chuyển trình duyệt tới nhà cung cấp danh tính của bạn khi SAML được cấu hình. Nếu bước đó qua, ứng dụng nhận một địa chỉ từ CIDR ứng dụng của endpoint và console hiển thị kết nối đang hoạt động. Không có thời điểm nào trong trao đổi đó hỏi liệu bạn có tới được 10.0.4.17 trên cổng 27017 hay không.

Quyền cho một đích là một đối tượng riêng trên endpoint. Mỗi luồng được đối chiếu với các quy tắc ủy quyền, và mỗi quy tắc ghép một CIDR đích với nhóm được cấp quy tắc. Khi không quy tắc nào bao phủ đích, endpoint chấp nhận phiên và bỏ lưu lượng. Không có banner, không có vòng kết nối lại, và không có gì trong giao diện ứng dụng nói bị từ chối.

So sánh quy tắc ủy quyền với tài nguyên, không phải với VPC

Liệt kê các quy tắc và đặt chúng cạnh địa chỉ mà phiên bản thực sự có:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Kết quả hiển thị một CIDR đích và một ID nhóm cho mỗi quy tắc. Có hai lỗi ẩn trong đó. Quy tắc có thể cho phép 10.0.0.0/16 trong khi phiên bản nằm trong VPC đã peer ở 10.1.0.0/16; tuyến peering tồn tại, nhưng không ai viết quy tắc ủy quyền cho dải thứ hai. Hoặc quy tắc trỏ tới một nhóm thư mục mà người dùng thuộc về trong thư mục nhưng không thuộc nhóm mà endpoint đánh giá.

Viết quy tắc hẹp nhất bao phủ đích, và chỉ thêm quy tắc thứ hai khi thực sự cần CIDR thứ hai. Một quy tắc rộng 0.0.0.0/0 từ bản khởi tạo nhanh vẫn chạy, và đó là lý do nó sống sót vào môi trường thật và che giấu mô hình.

Hai bảng tuyến quyết định gói tin có di chuyển hay không

Tuyến endpoint ánh xạ CIDR đích tới một trong các subnet mà endpoint được liên kết. Đó là nửa chặng đường. Bảng tuyến của chính subnet vẫn phải biết cách chuyển tiếp gói tin, và điều đó quan trọng ngay khi đích nằm sau một kết nối peering, một transit gateway hoặc một dải tại chỗ tiếp cận được qua đường hầm site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Tìm tuyến có đích khớp với CIDR của tài nguyên và đích đến là một subnet được liên kết. Nếu thiếu tuyến, hãy thêm. Nếu có mà máy chủ vẫn im lặng, khoảng trống nằm ở phía VPC, nên so với bảng tuyến của subnet liên kết.

Một thiết lập phía ứng dụng phá định tuyến mà không phá đường hầm: hồ sơ có chứa route-nopull. Chỉ thị đó bảo ứng dụng dựa trên OpenVPN bỏ qua các tuyến mà máy chủ đẩy xuống, nên giao diện chỉ lên với địa chỉ của chính endpoint và đích đơn giản là không có tuyến. Kiểm tra bằng ip route show trên Linux hoặc netstat -rn trên macOS xem có tuyến qua giao diện tun không. Nếu không, hãy bỏ route-nopull khỏi hồ sơ đã xuất và kết nối lại để các tuyến được đẩy vào có hiệu lực.

Nhóm bảo mật không thấy địa chỉ ứng dụng của bạn

Đây là phần tôi hiểu sai suốt một buổi chiều. Với endpoint IPv4 liên kết với một subnet, dịch vụ dịch địa chỉ nguồn của ứng dụng thành địa chỉ giao diện mạng của endpoint trong subnet đó. Gói tin đến phiên bản không mang địa chỉ mà ứng dụng của bạn hiển thị, nên một quy tắc nhóm bảo mật cho phép dải ứng dụng, ví dụ 172.16.0.0/22, không khớp với gì cả.

Cho phép cổng từ nhóm bảo mật của endpoint, nhóm gắn với giao diện của liên kết, chứ không từ CIDR ứng dụng. Tham chiếu nhóm bền hơn mã hóa cứng một địa chỉ, vì địa chỉ giao diện không thuộc quyền kiểm soát của bạn. ACL mạng không lưu trạng thái, nên ở nơi có mục tùy chỉnh, cả chiều vào và chiều ra đều phải cho phép luồng.

Kết nối cả tới địa chỉ riêng của phiên bản. IP công cộng đưa gói tin ra khỏi VPC và đưa vào lại bằng tuyến khác với quy tắc khác, nên thử qua địa chỉ công cộng không nói gì về tuyến riêng.

Một thứ tự cô lập dừng ở lỗi đầu tiên

Đi qua các bước này theo thứ tự và dừng ở chỗ một bước thất bại. Mỗi bước loại trừ một lớp chứ không phải tất cả.

1. Xác nhận phiên dùng danh tính nào và endpoint đánh giá nhóm nào. Chứng chỉ từ một trust store không phải cùng một chủ thể với một khẳng định SAML từ thư mục.
2. Xác nhận một quy tắc ủy quyền bao phủ CIDR của tài nguyên cho nhóm đó.
3. Xác nhận có tuyến endpoint và tuyến đó nhắm tới một subnet liên kết, rồi xác nhận bảng tuyến của subnet có thể chuyển tiếp xa hơn.
4. Xác nhận nhóm bảo mật cho phép cổng từ giao diện của endpoint chứ không từ dải ứng dụng.
5. Thử từ bên trong VPC, với một phiên SSM trên phiên bản khác cùng subnet, để tách vấn đề ứng dụng khỏi vấn đề tuyến của client.

Khi các bước không quyết định, bảng này là thứ tôi dựa vào:

Hai chi tiết tài khoản tạo ra triệu chứng giống lỗi quyền. Mỗi người dùng cần một chứng chỉ ứng dụng riêng; chia sẻ một chứng chỉ giữa hai máy khiến các phiên đẩy nhau ra, và kết quả là vòng kết nối lại chứ không phải từ chối. Khi một endpoint mới được tạo, console hiển thị một tên DNS mà một số phiên bản ứng dụng chỉ chấp nhận khi có tiền tố ngẫu nhiên hiển thị trên trang endpoint, nên hãy sao chép nguyên tên thay vì dựng lại.

Nếu bước thứ năm làm bạn tắc, hãy lấy nhật ký kết nối của endpoint và đọc các mục ủy quyền trước khi thay đổi bất cứ điều gì. Nhật ký nêu tên đích đã kiểm tra và quy tắc khớp hoặc không khớp, và điều đó thu câu hỏi bốn lớp thành một câu trả lời.