OpenVPN: bắt tay TLS thất bại – bạn đang ở nhánh nào?
Hết thời gian chờ, chứng chỉ bị từ chối và kênh điều khiển không khớp cần cách sửa khác nhau. Đọc các sự kiện trước khi ngắt kết nối để chọn đúng nhánh.
Dòng báo rằng bắt tay TLS thất bại là phần kết của câu chuyện, không phải phần mở đầu. Điều quan trọng là sự kiện ngay trước đó, vì sự kiện ấy gọi tên lỗi nào trong bốn lỗi rất khác nhau mà bạn gặp. Hết thời gian chờ, kênh điều khiển không khớp, chứng chỉ bị từ chối và lỗi sau khi thương lượng đều tạo ra cùng một tiêu đề. Chọn nhánh dựa trên bằng chứng, và cách sửa không còn là đoán mò.
Đọc sự kiện cuối cùng trước khi lỗi
Cuộn lên thay vì đọc dòng cuối. Sự kiện trước khi ngắt kết nối thường gọi tên giai đoạn: không có phản hồi nào, lỗi khi trao đổi gói điều khiển, kết quả xác minh, hoặc thương lượng thành công kèm kết quả xác thực danh tính. Mỗi thứ thuộc về một bên chịu trách nhiệm khác nhau. Chính dòng đó quyết định phần nào bên dưới được áp dụng.
Lưu văn bản lỗi cùng phiên bản ứng dụng khách, điểm cuối và phương thức truyền. Giữ khóa, mật khẩu và hồ sơ chưa biên tập ra khỏi mọi thứ bạn dán công khai.
Một lỗi đầu tiên chính xác đáng giá hơn một đoạn nhật ký dài. Nó gọi tên giai đoạn, và giai đoạn gọi tên bên chịu trách nhiệm.
Nhánh một: không có gì trả về
Nếu ứng dụng khách đã gửi gói đầu tiên và không nhận được gì dùng được, vấn đề nằm trên đường đi hoặc ở phía lắng nghe. Xác nhận hồ sơ khớp với một tùy chọn mà nhà cung cấp thực sự đưa ra: địa chỉ, cổng và UDP hoặc TCP. Sau đó kiểm tra xem điểm cuối có thể tiếp cận từ mạng này hay không. Ghi lại kiểm tra nào trong hai đã thất bại trước khi tiếp tục.
Trình duyệt tải một trang trên cùng tên máy chủ chỉ chứng minh rằng một dịch vụ web đã phản hồi. Ngay cả kết nối TCP được chấp nhận cũng không nói gì về việc OpenVPN đã hoàn tất thương lượng hay chưa.
Nếu hồ sơ hoạt động trên một mạng đáng tin cậy khác, hãy giữ lại so sánh đó. Nó khu trú hạn chế về một đường đi hoặc một bên trung gian.
Nhánh hai: kênh điều khiển không khớp
Khi quá trình trao đổi bắt đầu rồi khựng lại, cài đặt kênh điều khiển là nghi phạm đầu tiên. tls-auth và tls-crypt phải khớp với triển khai, và tài liệu từ máy chủ khác sẽ không tạo ra trao đổi hữu ích. Lỗi này xảy ra trước mọi lần đăng nhập tài khoản. Hồ sơ sao chép từ máy chủ cũ là nguồn thường gặp.
Đặt lại mật khẩu không thay thế các cài đặt đó, và mượn khóa từ dịch vụ khác không phải cách sửa tương thích. Lấy hồ sơ qua kênh đã xác minh của nhà cung cấp và ghi lại phiên bản ứng dụng khách mà nó mong đợi.
Ghi lại lỗi thương lượng cụ thể thay vì bật một loạt thuật toán cũ để xem cái nào trụ được. Văn bản lỗi thu được chính là thứ cho phép nhà cung cấp kiểm tra phía của họ.
Nhánh ba: một chứng chỉ bị từ chối
Một lỗi xác minh rõ ràng gọi tên chứng chỉ mà nó không ưa. Kiểm tra đồng hồ thiết bị trước, rồi đọc xem đối tượng nào đã thất bại: chứng chỉ máy chủ, chứng chỉ ứng dụng khách, hoặc nhà phát hành trong chuỗi. Hết hạn, nhà phát hành không được tin cậy và danh tính bất ngờ là ba thông điệp khác nhau.
Giữ xác minh bật trong khi bạn lấy tài liệu đã sửa. Chấp nhận một chứng chỉ không liên quan sẽ xóa lỗi mà không chứng minh rằng bạn đã đến đúng máy chủ.
Ghi lại xem lỗi đi theo mạng hay theo hồ sơ. Lỗi chứng chỉ xuất hiện ở mọi nơi không phải vấn đề đường đi.
Nhánh bốn: thương lượng đã xong và một thứ khác thất bại
Khi trao đổi danh tính thành công, lỗi còn lại thuộc về xác thực hoặc định tuyến. Từ chối tài khoản rõ ràng là câu hỏi xác thực, và một đường hầm đã kết nối mà không tới được trang web là câu hỏi định tuyến hoặc DNS. Tiếp tục thay tùy chọn TLS ở thời điểm đó sẽ làm hỏng một giai đoạn vốn đã hoạt động.
Khi báo cáo sự cố, hãy nói mọi mạng có thất bại không, hồ sơ khác có hoạt động không, và máy chủ có ghi lại lần thử không. Sự im lặng phía máy chủ và việc từ chối từ phía đó nằm ở những ranh giới khác nhau.