AWS Client VPN: đăng nhập thành công nhưng không tới được subnet
Đăng nhập AWS Client VPN thành công không có nghĩa là mọi subnet đều được cấp quyền. Hãy kiểm tra giá trị nhóm và quy tắc đích cụ thể nhất trước khi mở rộng quyền truy cập.
Máy khách của bạn báo Connected, chứng chỉ hợp lệ, nhưng trang intranet vẫn hết thời gian chờ. Khoảng cách đó gần như không bao giờ là xác thực. AWS Client VPN cấp quyền cho đích đến tách biệt với đăng nhập, và hai nguyên nhân thường gặp là giá trị nhóm không khớp với giá trị mà nhà cung cấp danh tính gửi và quy tắc đích cụ thể hơn đánh bại quy tắc rộng. Cả hai đều thấy được trong cấu hình endpoint khi biết chỗ để xem.
Đăng nhập thành công; quy tắc không khớp
Xác thực trả lời ai là người dùng. Các quy tắc cấp quyền trả lời danh tính đó được tới những tiền tố mạng nào. Người dùng có thể qua bước đầu và hỏng ở bước sau, còn máy khách chỉ cho bạn một kết nối vẫn mở trong khi mọi yêu cầu hết thời gian chờ.
Bắt đầu bằng việc xác nhận endpoint có quy tắc cấp quyền với đích chứa địa chỉ đang lỗi. Nếu không có quy tắc khớp, kết nối đang hành xử đúng; cái thiếu là chính sách.
Giá trị nhóm thực sự đến từ đâu
Với Active Directory, trường access-group giữ SID của nhóm, không phải tên hiển thị. Với liên kết SAML, trường này giữ ID hoặc tên nhóm mà thuộc tính nhóm SAML đã cấu hình thực sự mang theo. Sao chép giá trị từ assertion hoặc từ truy vấn thư mục, không phải từ trang wiki.
Nhóm IAM là một mặt phẳng điều khiển khác. Quyền quản trị endpoint Client VPN không biến nhóm IAM thành nhóm VPN của người dùng, và việc dán tên nhóm IAM vào trường access-group không chuyển nó thành SID của AD hay giá trị thuộc tính SAML.
Một nhóm có tên tương tự trong thư mục khác không chứng minh được gì. Hãy kiểm tra phương thức xác thực của endpoint và tư cách thành viên hoặc assertion của người dùng trong chính hệ thống đó.
Tiền tố dài nhất thắng, kể cả 0.0.0.0/0
Quyền được đánh giá theo khớp tiền tố dài nhất, và quy tắc cho mọi đích được đánh giá cuối cùng chứ không phải đầu tiên. Thêm quy tắc 10.46.0.0/16 cho Engineering và quy tắc 0.0.0.0/0 cho mọi người, người dùng ngoài Engineering vẫn không tới được 10.46.20.10 qua quy tắc rộng.
Đây là chỗ một bản sửa có thể đi sai. Xóa quy tắc hẹp sẽ khôi phục quyền của người dùng và đồng thời cấp subnet đó cho mọi danh tính mà quy tắc rộng bao phủ. Hãy dựng ma trận nhóm-tới-mạng trước khi xóa bất cứ thứ gì, và ghi lại nhóm nào phải tới dải nào. Những quy tắc này chỉ cho phép; không có mục từ chối để cắt một ngoại lệ ra khỏi một quyền rộng.
Thay đổi cũng cần một kết nối mới để được đánh giá công bằng. Kết nối lại máy khách sau khi sửa quy tắc, rồi kiểm tra lại.
Tách quyền khỏi đường dữ liệu
Một quy tắc khớp không phải là tuyến đường. Endpoint cần subnet được liên kết và một mục trong bảng tuyến cho đích, và nhóm bảo mật của tài nguyên đích phải chấp nhận lưu lượng. Lưu lượng phản hồi và DNS cũng phải hoạt động.
Hãy thử một người dùng nên thành công và một người dùng nên bị loại trừ. Cả hai đều đăng nhập được nhưng chỉ một người tới được subnet, và chính khác biệt đó là bằng chứng bạn cần.
Nếu địa chỉ IP hoạt động mà tên máy không, hãy xem resolver trước khi chạm vào phần cấp quyền. Nếu không tuyến nào phủ địa chỉ, hãy sửa liên kết hoặc bảng tuyến. Nếu gói tin đến mà dịch vụ từ chối, trạm tiếp theo là chính sách của dịch vụ đó. Mở rộng ma trận cấp quyền cho mọi người dùng sẽ che mất lớp nào thực sự hỏng.
Trước khi đóng phiếu, hãy ghi lại nguồn danh tính, giá trị nhóm chính xác, các tiền tố đích và tuyến đường mang lưu lượng. Bản ghi đó biến báo cáo đã kết nối nhưng không truy cập được lần sau thành một phép so sánh hai phút thay vì thêm một vòng đoán.