Hồ sơ được tải xuống, nhập vào rồi dừng ở dòng 12 của tệp với thông báo Unrecognized option nêu tên keysize. Không có gì thay đổi ở tài khoản, và máy chủ vẫn chấp nhận các máy khách khác. Thứ đã thay đổi là chính máy khách: Ubuntu 24.04 cài đặt OpenVPN 2.6, trong khi bản xuất được viết cho 2.4. Cách sửa là một loạt xóa ngắn, và thứ tự quan trọng vì mỗi tùy chọn cũ sẽ dừng việc phân tích trước khi tùy chọn tiếp theo được đọc.

Đọc dòng lỗi trước khi chạm vào tệp

OpenVPN nêu tên tệp và dòng nơi việc phân tích dừng lại, nên mỗi lần chạy bạn chỉ sửa được một vấn đề. Khởi chạy hồ sơ từ terminal thay vì applet trên màn hình, vì applet thường nuốt stderr và số dòng là manh mối đáng tin cậy duy nhất bạn có: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Sửa dòng đó, chạy lại, và chờ lỗi tiếp theo nêu một tùy chọn khác.

Lỗi phân tích luôn xuất hiện trước mọi bắt tay TLS, nên một thông báo nhắc đến chứng chỉ đã vượt qua giai đoạn cú pháp. Sự phân biệt đó giúp bạn không sửa một tệp chỉ hỏng ở khâu xác thực. Hãy đọc từ đầu tiên của thông báo chứ không phải phần giữa.

Ba nhóm lỗi, ba cách sửa khác nhau

Các bản xuất cũ hỏng theo ba cách có thể phân biệt, và việc gộp chúng thành một vấn đề là lý do người ta cài lại những gói chưa bao giờ hỏng. Cách diễn đạt của thông báo cho bạn biết mình ở nhóm nào trước khi mở tệp.

  • Lỗi phân tích nêu tên tệp và dòng, rồi dừng trước khi có bất kỳ lưu lượng nào.
  • Lỗi thương lượng kết nối được, rồi báo rằng hai đầu không thống nhất được mật mã dùng chung hoặc kênh dữ liệu chấp nhận được.
  • Lỗi xác thực đi xa nhất và nêu tên chứng chỉ, người dùng hoặc thông tin đăng nhập bị từ chối.

Sửa hồ sơ chỉ khắc phục nhóm đầu tiên. Thương lượng cần quyết định ở cả hai đầu đường hầm, và thông tin đăng nhập bị từ chối hoàn toàn không phải vấn đề cú pháp. Nếu thông báo của bạn nhắc đến mật mã dùng chung hoặc kênh dữ liệu, các thao tác xóa bên dưới sẽ không thay đổi gì.

Xóa các tùy chọn mà 2.6 đã bỏ, theo thứ tự này

Mỗi dòng trong số này tự dừng việc phân tích, nên máy khách báo từng dòng một. Đi xuống danh sách và chạy lại sau mỗi lần xóa.

Gỡ keysize trước, vì nó không có tương đương hiện đại và sự hiện diện của nó thường đánh dấu một mật mã mà máy khách hiện tại vốn từ chối. Sau đó gỡ ncp-disable, tùy chọn điều khiển thương lượng mật mã, đã bị ngừng dùng ở 2.5 và biến mất ở 2.6. Thay ns-cert-type server bằng remote-cert-tls server, tùy chọn diễn đạt cùng ý định thông qua một kiểm tra được hỗ trợ.Lịch sử thay đổi 2.6 liệt kê các mục bị bỏ còn lại bên cạnh phần thay thế, nên bất cứ điều gì trình phân tích vẫn từ chối đều có câu trả lời được ghi lại.

Giữ một bản sao của hồ sơ gốc trước lần sửa đầu tiên. Nhà cung cấp thực sự tạo lại bản xuất, và so sánh với tệp chưa bị chạm là cách nhanh nhất để tách thay đổi của bạn khỏi của họ. Nếu một thao tác xóa cho phép máy khách khởi động nhưng đường hầm vẫn hỏng,bạn đã chuyển sang nhóm thương lượng và các dòng còn lại không phải nguyên nhân. Đặt phiên bản máy khách vào tên tệp để người tiếp theo biết các sửa đổi nhắm tới bản phát hành nào.

Chỉ giữ BF-CBC hoạt động như một phương án dự phòng có giới hạn

Một số nhà cung cấp vẫn kết thúc trên BF-CBC, thứ mà OpenVPN 2.6 không thương lượng nếu không có trợ giúp vì mật mã này có khối 64 bit. Cách sửa hẹp là danh sách dự phòng cộng với nhà cung cấp legacy của OpenSSL, không phải hạ cấp toàn bộ máy khách.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

Dòng đầu nạp nhà cung cấp legacy để OpenSSL vẫn tạo được mật mã đó, dòng thứ hai giữ thương lượng hiện đại cho các bên hỗ trợ nó, và dòng thứ ba chỉ áp dụng khi máy chủ không cung cấp gì tốt hơn. Đây là sự làm yếu đường hầm có chủ đích, nên hãy ghi lý do tồn tại của nó bên cạnh tệp. Đồng thời yêu cầu nhà cung cấp một bản xuất được tạo lại, vì dự phòng là cầu nối chứ không phải đích đến.

Đừng dùng --compat-mode như câu trả lời phổ quát. Nó thay đổi nhiều hành vi cùng lúc, gồm mặc định thương lượng và thương lượng lại, nên bạn không bao giờ biết thay đổi nào quan trọng. Hãy ưu tiên ba dòng rõ ràng ở trên, vì mỗi dòng nêu hiệu ứng của riêng nó.

Xác minh bằng hồ sơ mà máy khách thực sự nạp

Các kết nối đã nhập thường được sao chép vào thư mục hệ thống, nên việc sửa tệp trong thư mục tải xuống của bạn có thể không thay đổi gì cả. Tìm bản sao đang chạy: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Sau đó khởi chạy đường hầm và đọc dòng nhật ký báo mật mã kênh dữ liệu thực sự được chọn. Một kết nối hoàn tất bắt tay trên phương án dự phòng cho bạn biết máy chủ chưa bao giờ cung cấp thứ gì hiện đại.

Thử từ một mạng không phải mạng nhà cung cấp mong đợi, để cổng captive hoặc mạng khách bị lọc không giả dạng thành lỗi hồ sơ. Ghi phiên bản máy khách cùng với mọi yêu cầu hỗ trợ.

Khi đường hầm đã lên, gửi một yêu cầu buộc phải đi qua nó và một yêu cầu không được đi qua, rồi xác nhận câu trả lời của trình phân giải đã thay đổi như bạn mong đợi. Nếu hồ sơ giờ đã phân tích được nhưng kết nối vẫn hỏng, bạn đã bỏ lại vấn đề cú pháp phía sau và văn bản lỗi sẽ nêu nhóm mới. Giữ tệp đã sửa trong hệ thống quản lý phiên bản bên cạnh ghi chú nêu bản phát hành OpenVPN mà nó nhắm tới.

Bài viết liên quan