OpenVPN báo ncp-disable không được nhận diện: điều gì đã thay thế nó?

Máy khách từ chối khởi động với lỗi tùy chọn nêu tên ncp-disable, dù hồ sơ đã chạy được trên máy trước. Thông báo đó không có nghĩa là tùy chọn bị viết sai hay mã hóa bị hỏng. Nó có nghĩa là tệp nhị phân trước mặt bạn hoàn toàn không biết chỉ thị này, và có hai lý do rất khác nhau cho điều đó. Lý do nào đúng sẽ quyết định bạn sửa hồ sơ hay đổi máy khách.

Lỗi có thể đến từ tệp nhị phân mới hơn

Lỗi tùy chọn không được nhận diện liên quan đến bộ phân tích, không phải đường hầm. OpenVPN 2.4 thêm các tham số mã hóa có thể thương lượng, 2.5 tuyên bố công tắc vô hiệu hóa chúng là lỗi thời, và 2.6 loại bỏ hoàn toàn. Vì vậy một hồ sơ viết cho 2.3 hoặc 2.4 sẽ thất bại trên máy khách hiện tại dù không có gì trong tệp thay đổi. Phiên bản phàn nàn là mới hơn, không phải cũ hơn.

Xác định tệp thực thi nào tạo ra thông báo trước khi sửa bất cứ điều gì. Máy khách desktop mang theo động cơ riêng, còn tệp nhị phân dòng lệnh cài riêng có phiên bản riêng. Hai bên có thể không khớp trên cùng một máy.

openvpn --version giải quyết điều đó cho tệp nhị phân bạn đang kiểm tra. Máy khách GUI có thể không hiển thị lệnh đó; khi ấy hãy đọc màn hình giới thiệu hoặc phiên bản thư viện đi kèm.

Tùy chọn thực sự kiểm soát điều gì

Chỉ thị này tắt việc thương lượng các tham số mật mã, nên cả hai đầu quay về hành vi chọn cũ do thiết lập cipher điều khiển. Nó chưa bao giờ tắt mã hóa và chưa bao giờ biến đường hầm thành văn bản thuần. Đọc nó như một công tắc bảo mật là ngã rẽ sai đầu tiên, và điều đó dẫn đến những thay đổi làm kết nối tệ đi thay vì tốt hơn.

Khi đã có thương lượng, câu hỏi tương đương là mỗi bên sẵn sàng dùng những mã hóa nào. Đó là câu hỏi chính sách, và chính sách nằm trong data-ciphers từ 2.5 trở đi.

Tên cũ ncp-ciphers thuộc về 2.4. Trộn hai tên giữa các bên là nguồn phổ biến của thất bại thương lượng một chiều. Một hồ sơ mang cả hai là hồ sơ do hai người sửa ở hai thời điểm khác nhau.

Thay chính sách, không thay cách viết

Đặt data-ciphers trên cả hai bên với lựa chọn chung dự kiến, và giữ danh sách đủ ngắn để người phản biện có thể lý luận về nó. Thay một dòng tùy tiện không chứng minh được gì; kết quả phụ thuộc vào phần giao của hai danh sách và vào điều ngăn xếp TLS hỗ trợ. Xác nhận các bên đồng thuận bằng cách đọc kết quả thương lượng thay vì cấu hình. Sau đó ghi cả hai danh sách vào hồ sơ triển khai để thay đổi tiếp theo bắt đầu từ trạng thái đã biết.

Cập nhật hồ sơ thông qua người sở hữu nó. Thêm tùy chọn bỏ qua để che giấu một chỉ thị lỗi thời để lại câu hỏi chính sách không có câu trả lời.

Nếu một bên cũ thực sự cần xử lý tương thích, hãy giới hạn nó trong lần triển khai đó. Khôi phục hành vi lỗi thời trên toàn cầu không phải điều kiện tiên quyết để kết nối các bên hiện đại. Ngoại lệ nên nêu tên bên mà nó tồn tại vì bên đó.

Hai dòng trông như danh sách mã hóa nhưng không phải

Xếp chồng hai dòng mã hóa cũng không khôi phục thương lượng, và kết quả là một hồ sơ trông như danh sách nhưng hành xử như một giá trị duy nhất. Một dòng nêu AES-256-CBC và dòng tiếp theo nêu CBC là nỗ lực phổ biến. CBC một mình nêu tên một chế độ, không phải thuật toán, nên bộ phân tích có thể chấp nhận ở chỗ này và từ chối ở chỗ tiếp theo. Các chỉ thị cipher lặp lại đặt cùng một tùy chọn hai lần thay vì tích lũy ứng viên.

Kiểm tra các tên được chấp nhận bằng openvpn --show-ciphers trên tệp nhị phân mục tiêu thay vì sao chép danh sách từ hướng dẫn viết cho nhánh khác. Danh sách thay đổi giữa các bản phát hành. Một tên hợp lệ trong nhánh này không nhất thiết hợp lệ trong nhánh kia.

Nếu mục tiêu là so sánh hiệu năng, hãy ghi lại thuật toán và khối lượng công việc. Chuyển sang CBC không phải là phép đo cho thấy không có mã hóa.

Kiểm tra điều kết nối thực sự đã thương lượng

Mở một kết nối mới và đọc dòng kênh dữ liệu trong nhật ký, nơi nêu mã hóa đang dùng. Bộ kênh điều khiển được quyết định riêng, nên danh sách được phép trong tệp chỉ cho thấy những gì đã được đề nghị. Khi hai bên chọn điều bạn không ngờ, danh sách mới là nơi cần xem chứ không phải giao diện đường hầm. Xác nhận kết quả trên kết nối thứ hai sau mọi thay đổi, vì một lần khởi động lại có thể tái sử dụng phiên đã lưu trong bộ nhớ đệm.

Giữ kết quả thương lượng trong hồ sơ triển khai bên cạnh phiên bản hồ sơ. Đó chính là dữ kiện trả lời câu hỏi tiếp theo về việc mã hóa nào thực sự bảo vệ lưu lượng.