OpenVPN không có chứng chỉ máy khách: chính sách máy chủ, không phải hồ sơ

Bạn xóa các dòng chứng chỉ và khóa, giao hồ sơ đi, và kết nối vẫn thất bại với lỗi chứng chỉ. Hồ sơ chưa bao giờ là thứ thực thi yêu cầu đó. Máy chủ quyết định chứng chỉ máy khách có bắt buộc hay không, và không chỉnh sửa nào phía máy khách thương lượng để bỏ nó đi. Vì vậy cách khắc phục là thay đổi chính sách máy chủ, được thực hiện có chủ đích, với mọi thứ phụ thuộc vào nó được cập nhật trong cùng một lượt.

Hồ sơ không phải chính sách

Community OpenVPN 2.6 đi kèm chứng chỉ máy khách bắt buộc, vì verify-client-cert mặc định là require. Đặt nó thành none chính là điều dừng yêu cầu chứng chỉ và giao việc xác thực máy khách cho cách bố trí tên người dùng và mật khẩu mà máy chủ đã vận hành. Các hướng dẫn cũ với tay tới client-cert-not-required, cách viết cũ của cùng ý tưởng, nên hãy dùng chỉ thị mà phiên bản đã cài của bạn ghi lại. Dù thế nào, thay đổi diễn ra trên máy chủ, và không hồ sơ máy khách nào có thể thực hiện nó.

Đoạn dưới đây là toàn bộ thay đổi phía máy chủ, và tự nó không phải là cấu hình xác thực hoạt động được. verify-client-cert none loại bỏ yêu cầu chứng chỉ, trong khi username-as-common-name biến tên tài khoản thành danh tính mà các lệnh gọi lại sau này và các tệp theo từng máy khách nhìn thấy. Không dòng nào kiểm tra mật khẩu, nên vẫn phải có một bộ xác minh.

verify-client-cert none
username-as-common-name

Bộ xác minh đó là một plugin hoặc một script do auth-user-pass-verify điều khiển, và nó phải có mặt trước khi bất kỳ dòng nào ở trên có ý nghĩa. Đảo ngược thứ tự cho bạn một khoảng thời gian mà máy chủ không yêu cầu chứng chỉ và không kiểm tra tài khoản nào.

Điều gì vẫn xác minh máy chủ

Bỏ chứng chỉ máy khách không phải là bỏ TLS. Máy chủ giữ chứng chỉ và khóa của mình, và máy khách giữ niềm tin CA cùng các kiểm tra tên máy chủ ngăn nó nói chuyện với kẻ giả mạo. Gỡ remote-cert-tls server hoặc gói CA vì máy khách không còn chứng chỉ là một cách đọc sai phổ biến và nghiêm trọng, và tài liệu tham chiếu 2.6 nói rõ hai hướng là độc lập. Một cái chứng minh máy chủ với máy khách; cái kia chứng minh máy khách với máy chủ.

Hồ sơ cũng có thể mang một khối tls-auth hoặc tls-crypt. Đó là khóa kênh điều khiển dùng chung với chu kỳ phân phối và luân chuyển riêng, nên một tệp không có dòng chứng chỉ hay khóa không tự động an toàn để công bố. Hãy đối xử với nó như một bí mật cho đến khi bạn đọc nó.

Một tệp chứng chỉ được sao chép từ hồ sơ đang hoạt động không chứng minh gì tự nó; sở hữu nghĩa là giữ khóa riêng tương ứng, điều mà một triển khai xác thực bằng chứng chỉ kiểm tra. Một tệp chứa chứng chỉ không phải là tệp có thể xác thực bằng nó.

Bộ xác minh phải làm gì

Khi yêu cầu chứng chỉ bị loại bỏ, mọi thứ dựa vào bộ xác minh: một plugin, hoặc một script do auth-user-pass-verify điều khiển. Nó phải từ chối thông tin đăng nhập không hợp lệ, từ chối tài khoản bị vô hiệu hóa hoặc không đủ điều kiện, và thất bại theo hướng đóng khi không thể chạm tới backend của nó. username-as-common-name thường được bật bên cạnh, và nó thay đổi danh tính mà các lệnh gọi lại sau này và tệp cấu hình theo từng máy khách nhìn thấy. Nó không xác minh mật khẩu, và không làm cho một tài khoản không đủ điều kiện trở nên đủ điều kiện. Đó là những công việc riêng biệt, và trộn lẫn chúng là cách một cuộc di trú vượt qua bài kiểm tra đường đi hạnh phúc và thất bại ở sự cố thực tế đầu tiên.

Hãy kiểm tra các trường hợp phủ định cẩn thận như trường hợp khẳng định. Một hồ sơ hiển thị lời nhắc mật khẩu chỉ chứng minh rằng máy khách vẽ được một lời nhắc, trong khi một máy chủ chấp nhận mật khẩu sai chứng minh điều gì đó tồi tệ hơn nhiều. Hãy thêm một tài khoản bị vô hiệu hóa và một thông tin đăng nhập đã hết hạn vào bộ kiểm tra, không chỉ một mật khẩu tồi.

Thay đổi chính sách, hồ sơ và ánh xạ cùng nhau

Phối hợp ba thứ: chỉ thị máy chủ, hồ sơ máy khách và ánh xạ danh tính theo từng máy khách. Thay đổi chúng riêng lẻ và máy khách thất bại trước khi xác thực, hoặc kết nối dưới một tên mà quản trị viên không ngờ tới, điều này tệ hơn vì nó trông giống thành công. Một kết nối thành công dưới danh tính sai khó nhận ra hơn một kết nối thất bại.

Giữ hai tài khoản kiểm tra cho đường đi này, một hợp lệ và một đã biết là xấu, và dùng cả hai sau mọi thay đổi đối với bộ xác minh. Tài khoản hợp lệ chứng minh đường đi hạnh phúc và ánh xạ danh tính; tài khoản xấu chứng minh rằng việc từ chối vẫn hoạt động. Không bài kiểm tra nào cho bạn biết gì về các quy tắc đủ điều kiện, nên hãy thêm một tài khoản đáng lẽ phải bị từ chối vì lý do chính sách nếu triển khai có những quy tắc đó. Chạy cả ba sau mỗi thay đổi, vì một bộ xác minh bắt đầu chấp nhận mọi thứ trông giống hệt một lần đăng nhập hoạt động.

Ghi lại những phương thức xác thực mà máy chủ thực sự chấp nhận, không phải những phương thức mà hồ sơ gợi ý. Bản ghi đó trả lời câu hỏi mà mọi người cứ hỏi, đó là ai có thể kết nối với dịch vụ này. Nó cũng sống lâu hơn quản trị viên tiếp theo, người nếu không sẽ khám phá lại nó từ một bản chụp gói tin.