Đăng nhập OpenConnect rơi vào trang sai? Hãy kiểm tra đường dẫn trước

Bạn dán địa chỉ từ email giới thiệu, ứng dụng khách đến được cổng, và biểu mẫu đăng nhập hiện ra là cổng chung chứ không phải cổng đối tác mà người vận hành đã mô tả. Không có gì báo lỗi, và chính điều đó gây khó hiểu: đường hầm thậm chí có thể lên, chỉ là phía sau một điểm vào sai. Đường dẫn trong URL đó đang làm việc, và bất cứ thứ gì thay thế nó đã bỏ rơi công việc đó.

Tách hai thứ đến như một chuỗi duy nhất trong phiếu: địa chỉ đến được dịch vụ, và đầu vào quyết định nơi bắt đầu xác thực. Sửa cái đầu trong khi bỏ qua cái sau là cách một tên máy chủ đúng vẫn tạo ra đăng nhập sai.

Ứng dụng khách gửi gì trước khi bạn thấy biểu mẫu

Với địa chỉ như https://vpn.example.net/partners, hành động đầu tiên của ứng dụng khách là yêu cầu HTTPS tới chính đường dẫn đó chứ không phải tới máy chủ trần. Thứ quay về thường là chuyển hướng tới điểm đăng nhập, hoặc chính biểu mẫu. Ứng dụng khách chỉ được cấp vpn.example.net sẽ bắt đầu từ trang đích mặc định nào đó, và đó có thể là một cổng khác, một danh sách nhóm khác, hoặc một trang chờ đợi giao thức hoàn toàn khác. Sự khác biệt hiện ra trong tiêu đề phản hồi rất lâu trước khi bất kỳ thông tin đăng nhập nào được gõ.

Đó là lý do một tab trình duyệt hoạt động và một hồ sơ ứng dụng khách thất bại có thể gọi cùng một cổng mà vẫn không khớp nhau. Trình duyệt đã đi theo đường dẫn; hồ sơ chưa bao giờ có nó.

Hai đầu vào trông có thể hoán đổi và không phải vậy

OpenConnect công bố đường dẫn HTTPS ban đầu dưới dạng --usergroup, và trang hướng dẫn coi URL đầy đủ mang đường dẫn đó là cùng một yêu cầu được viết theo cách khác. --authgroup là một tùy chọn riêng: nó chọn một mục từ danh sách mà cổng trình bày bên trong biểu mẫu đăng nhập. Một số giao thức gọi mục đó là nhóm, số khác gọi là miền hoặc cổng, và chính ở đó hai cờ bị nhầm lẫn.

Một dịch vụ có thể cần cả hai một cách hợp lệ. Đường dẫn có thể đưa bạn tới đúng cổng trong khi biểu mẫu vẫn yêu cầu chọn trong các nhóm bên trong nó. Đưa tên cổng làm tên nhóm, hoặc ngược lại, tạo ra đăng nhập trông như được chấp nhận rồi không cấp quyền, vì giá trị đúng về cú pháp nhưng sai về ngữ nghĩa.

Hãy yêu cầu người vận hành cung cấp từng giá trị trên dòng riêng: đường dẫn vào, lựa chọn trong biểu mẫu, và liệu cả hai có cần thiết không. Đừng suy ra cái này từ cái kia chỉ vì nhãn nghe giống nhau.

Tại sao cắt bớt đường dẫn lại thay đổi kết quả

Ứng dụng khách chỉ chấp nhận máy chủ và cổng thường vẫn kết nối được, nên triệu chứng hiếm khi là thất bại cứng. Thay vào đó bạn nhận được trang đăng nhập sai, danh sách nhóm rỗng, tên chứng chỉ không còn khớp với thứ người vận hành đã công bố, hoặc một đường hầm lên mà không có tuyến tới dịch vụ bạn muốn. Mỗi thứ trong số đó nằm ở một tầng khác nhau, và không thứ nào được sửa bằng cách dán một chuỗi dài hơn vào trường được ghi là tên máy chủ. Hai trong số đó còn không thể phân biệt từ bên ngoài, vì cả hai đến như một biểu mẫu đăng nhập đơn giản là không tiếp tục.

Thay tên máy chủ bằng địa chỉ IP là một lỗi riêng thường đi cùng lỗi này. Chọn dịch vụ dựa trên tên và xác thực chứng chỉ đều phụ thuộc vào tên, nên một địa chỉ số có thể biến vấn đề định dạng đường dẫn thành lỗi TLS.

Địa chỉ trình duyệt còn mang nhiều hơn cả đường dẫn. Mã phiên, đích chuyển hướng, tiền tố ngôn ngữ và tham số đăng nhập tạm thời đều xuất hiện trên thanh địa chỉ, và không thứ nào trong đó thuộc về một hồ sơ ứng dụng khách đã lưu.

Xác nhận điểm vào trước khi sửa bất cứ thứ gì khác

Đọc các tiêu đề của đường dẫn bạn được cấp. Một yêu cầu như curl -sS -o /dev/null -D - https://vpn.example.net/partners in ra dòng trạng thái và mọi tiêu đề Location mà không theo chuyển hướng. Mã 302 trỏ tới một điểm đăng nhập có tên xác nhận đường dẫn tồn tại và cho biết nó đi đâu; mã 404 nghĩa là địa chỉ của người vận hành đã lỗi thời.

Sau đó tái tạo đúng điểm vào ấy trong ứng dụng khách đã được phê duyệt, ví dụ openconnect --usergroup=partners vpn.example.net, và xem biểu mẫu nào xuất hiện. Nếu biểu mẫu đúng mà đường hầm vẫn thất bại, đường dẫn chưa bao giờ là vấn đề và điểm dừng tiếp theo là chính sách hoặc định tuyến.

Ghi lại tên máy chủ, cổng, giao thức, đường dẫn vào và lựa chọn trong biểu mẫu thành năm trường riêng biệt trong phiếu. Chính danh sách đó giúp kỹ sư tiếp theo phân biệt một máy chủ không thể tới được với một lần từ chối TLS, một lựa chọn bị từ chối và một đường hầm lên mà không có các tuyến cần thiết.