Máy khách nào có thể hoàn tất đăng nhập SAML trong AWS Client VPN
Máy tính Linux có ứng dụng khách AWS hoàn tất được bước chuyển SAML trên trình duyệt; bản nhập OpenVPN thông thường trên Android thì không. Ba điều kiện quyết định trường hợp của bạn.
Hai người đặt cùng một câu hỏi về AWS Client VPN và SAML nhưng nhận được câu trả lời trái ngược. Một người đăng nhập từ máy tính xách tay Ubuntu mỗi sáng; người kia có điện thoại, một hồ sơ đã tải xuống và một ứng dụng khách từ chối một dòng trong đó. Sự khác biệt không phải may mắn và cũng không phải một công tắc ẩn trên bảng điều khiển. Tất cả nằm ở ba điều kiện: nền tảng có phải một trong những nền tảng AWS hỗ trợ cho ứng dụng khách của chính mình, công cụ trong tay bạn có thực hiện được trao đổi trình duyệt liên kết hay không, và điểm cuối có được cấu hình cho SAML hay không. Thiếu một trong ba thì đăng nhập dừng ở một chỗ khác.
Ba điều kiện quyết định đăng nhập có thể hoàn tất hay không
Nền tảng đứng đầu tiên. AWS cung cấp ứng dụng khách Client VPN của riêng mình cho Windows, macOS và Ubuntu trên AMD64, và vào cuối tháng Mười năm 2026 trang yêu cầu Linux nêu Ubuntu 22.04, 24.04 và 26.04. Một bản dựng đóng gói lại, một gói đã chuyển đổi hoặc một bản phân phối khác có thể chạy được, nhưng đó không phải nền tảng được hỗ trợ, và khi nó hỏng thì bạn chính là bộ phận hỗ trợ.
Ứng dụng khách đứng thứ hai. Đăng nhập liên kết không phải một tùy chọn hồ sơ mà mọi ứng dụng tương thích OpenVPN đều phân tích. Ứng dụng khách được cung cấp mở nhà cung cấp danh tính của bạn trong trình duyệt, nhận phản hồi xác thực đã ký và gửi phản hồi đó đến điểm cuối. Một ứng dụng chỉ đọc hồ sơ rồi dựng đường hầm không thực hiện bước này, dù nhật ký kết nối của nó trông sạch đến đâu.
Điểm cuối đứng thứ ba. Một điểm cuối dùng thông tin đăng nhập Active Directory hoặc chứng chỉ tương hỗ có cách bố trí hoàn toàn khác, và việc đổi ứng dụng khách sẽ không thay đổi điều đó. Hãy xác nhận chế độ xác thực với người đã phát hành hồ sơ trước khi gỡ lỗi bất cứ điều gì khác.
Kết hợp lại, ba điều kiện cho một bảng quyết định ngắn:
| Platform | AWS-provided client | Completes the SAML exchange | What that means |
|---|---|---|---|
| Ubuntu 22.04 / 24.04 / 26.04, AMD64 | Yes | Yes | Normal sign-in path; debug stages, not platforms |
| Windows or macOS | Yes | Yes | Same path, different installer |
| Android | No published client | No | Needs a different access design, not a different profile |
| Other Linux distributions | No | Depends on the tool | Runs at your own support risk |
Vì sao bản nhập OpenVPN dừng ở auth-federate
Một hồ sơ AWS Client VPN đã xuất mang theo chỉ thị cho ứng dụng khách biết rằng xác thực diễn ra bên ngoài đường hầm, thông qua liên kết. Một ứng dụng khách OpenVPN thông thường hoặc từ chối thẳng dòng đó, hoặc bỏ qua nó và khi đó không còn thông tin đăng nhập nào để đưa ra. Đây là nơi phần lớn các nỗ lực trên Android kết thúc: hồ sơ được nhập, ứng dụng phản đối, hoặc kết nối chết với lỗi cấu hình trước khi một gói tin rời khỏi thiết bị.
Xóa auth-federate là bước tiếp theo đầy cám dỗ, và nó biến một lỗi rõ ràng thành một lỗi khó hiểu. Việc bỏ một chỉ thị không biến điểm cuối SAML thành xác thực bằng tên người dùng và mật khẩu. Điểm cuối vẫn chờ một phản hồi SAML đã ký và từ chối thứ mà ứng dụng khách gửi thay vào đó. Mật khẩu tài khoản của bạn, hồ sơ đã tải xuống và một khẳng định được sao chép không phải là thông tin đăng nhập có thể hoán đổi cho nhau.
Đăng nhập vào nhà cung cấp danh tính trong Chrome trên điện thoại chỉ chứng minh rằng nhà cung cấp danh tính đã chấp nhận người dùng. Nó không nói gì về việc phản hồi có đến được một ứng dụng khách có thể gửi nó trở lại điểm cuối hay không. các yêu cầu về xác thực liên kết khiến ứng dụng khách được cung cấp trở thành một phần của luồng chính vì lý do đó: bước trên trình duyệt là cần thiết và chưa đủ.
Con đường máy tính Linux được hỗ trợ trông như thế nào
Cài đặt gói mà AWS công bố cho Ubuntu AMD64 bằng trình quản lý gói của hệ thống, sau đó mở kết nối từ ứng dụng khách đó thay vì nhập hồ sơ vào một ứng dụng VPN tổng quát. Dùng hồ sơ mà quản trị viên của bạn đã xuất cho điểm cuối này; đừng thay URL gọi lại hay mã định danh ứng dụng khách từ một hướng dẫn cũ, kể cả khi ứng dụng khách chấp nhận nó.
Khởi động kết nối, hoàn tất đăng nhập và mọi yêu cầu MFA trong trình duyệt mở ra, rồi để luồng quay lại từ trình duyệt về ứng dụng khách chạy xong. Sau đó yêu cầu lại địa chỉ riêng mà bạn thực sự cần. Một trang thông báo đăng nhập thành công không phải bằng chứng rằng đường hầm đã lên.
Ứng dụng khách Linux dành riêng các cổng TCP cục bộ từ 8096 đến 8115 cho phản hồi SAML. Khi bước chuyển bị treo sau khi nhà cung cấp danh tính đã chấp nhận bạn, hãy xem thứ gì đang lắng nghe trong dải đó:
ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"
Một cổng đang bị chiếm, hoặc phần mềm bảo mật điểm cuối chặn trình lắng nghe loopback, tạo ra một lần đăng nhập trông như đã xong rồi không bao giờ kết nối. Hãy giữ dải đó ở cục bộ. Đây là đường quay lại phía máy khách, không phải thứ để mở trong nhóm bảo mật EC2 hay quy tắc tường lửa của cổng, và mở nó ra internet chỉ tăng phơi nhiễm mà không sửa được gì.
Đọc bước thất bại trước khi thay đổi bất cứ điều gì
Đổ lỗi cho ứng dụng khách là phản xạ thường gặp, nhưng mỗi điểm thất bại thuộc về một chủ sở hữu khác. Trước hết hãy xác định bạn thực sự đang ở đâu.
- Không có cửa sổ trình duyệt nào mở ra. Kiểm tra chế độ xác thực của hồ sơ, kết nối bạn đã chọn và tích hợp với trình duyệt mặc định của máy tính.
- Nhà cung cấp danh tính từ chối tài khoản. Việc gán tài khoản, đăng ký MFA hoặc cấu hình ứng dụng SAML, tất cả đều thuộc địa hạt quản trị viên.
- Trình duyệt chạy xong nhưng ứng dụng khách không bao giờ kết nối. Một phản hồi xác thực đã hết hạn hoặc không dùng được, một cổng quay lại bị chặn, hoặc một lần chuyển giao thất bại.
- Đường hầm đã lên nhưng ứng dụng không truy cập được. Các tuyến của điểm cuối, quy tắc ủy quyền, nhóm bảo mật, DNS. Lặp lại đăng nhập trên trình duyệt không thể thêm một quyền mạng còn thiếu.
Giữ lại văn bản lỗi của ứng dụng khách và thời điểm thử khi bạn chuyển cấp. Khẳng định rằng SAML bị hỏng và khẳng định rằng ứng dụng khách chưa bao giờ nhận được phản hồi xác thực hợp lệ đưa người ta đến những nơi hoàn toàn khác nhau.
Khi yêu cầu vẫn là Android
Android không phải nền tảng mà AWS công bố ứng dụng khách của mình, vì vậy câu trả lời trung thực là không có ứng dụng khách di động được hỗ trợ để cài đặt. Đây là một giới hạn thiết kế, không phải câu đố cần giải trên điện thoại bằng cách sửa hồ sơ cho đến khi có thứ gì đó kết nối.
Điều có thể thay đổi là thiết kế truy cập phía sau, và quyết định đó thuộc về quản trị viên: một đường truy cập ứng dụng đã được phê duyệt tới dịch vụ nội bộ duy nhất mà điện thoại cần, một sản phẩm VPN hỗ trợ di động mà tổ chức đã vận hành, hoặc một máy tính được hỗ trợ cho điểm cuối chỉ dùng SAML. Mỗi lựa chọn mang theo cấu hình điểm cuối, đăng ký danh tính và quy tắc ủy quyền riêng, và người dùng không thể tạo ra bất kỳ thứ nào trong số đó từ một hồ sơ đã tải xuống.
Các công cụ của bên thứ ba tự nhận lấp được khoảng trống này cần một đánh giá rõ ràng về hỗ trợ và bảo mật bao gồm MFA, xử lý phản hồi, chính sách thiết bị và nhịp cập nhật. Sự tồn tại của chúng không biến chúng thành ứng dụng khách Android do AWS cung cấp, và bạn không nên chuyển vật liệu xác thực dùng lại được sang điện thoại để một trong số chúng hoạt động.
Hãy cho quản trị viên ba dữ kiện thay vì một chuỗi trao đổi dài về các chỉ thị: chế độ xác thực của điểm cuối, tài nguyên riêng mà điện thoại phải chạm tới, và hạn chót. Thế là đủ để chọn giữa máy tính, đường truy cập ứng dụng và một sản phẩm VPN mới.
Kiểm tra các điều kiện theo thứ tự trước khi mở thêm một phiếu: nền tảng nằm trong danh sách ứng dụng khách được cung cấp, một công cụ hoàn tất được trao đổi trên trình duyệt, một điểm cuối thực sự được cấu hình cho liên kết và, trên Linux, dải cổng loopback. Mục đầu tiên thất bại chính là thứ cần sửa. Mọi thứ sau đó chỉ là phỏng đoán.