Một listener chết trên DD-WRT thường có nghĩa là daemon đã thoát khi đang phân tích cấu hình của nó, chứ không phải một quy tắc tường lửa đã chặn cổng. OpenVPN 2.5 đã siết chặt một số giá trị mặc định mà các cấu hình cũ dựa vào, và một cấu hình được tạo từng chạy trên bản build cũ có thể bị từ chối trước khi socket kịp mở. Nguyên nhân nằm trong nhật ký của chính router, và đầu vào nằm trong tệp được tạo. Đọc cả hai theo thứ tự đó nhanh hơn mọi cách bắt gói tin.

Daemon không phải tường lửa

Sự phân biệt này quan trọng vì từ bên ngoài hai lỗi trông giống hệt nhau: máy khách gửi một handshake và không nhận lại gì. Một bên là tiến trình không chạy, bên kia là tiến trình đang chạy và lọc.

Hãy tách hai trường hợp bằng hai lần kiểm tra trước khi thay đổi bất cứ thứ gì, vì sửa tường lửa trên một daemon đã chết chỉ thêm một biến số thứ hai.

Đọc cấu hình mà DD-WRT đã tạo

DD-WRT không đưa cho OpenVPN đoạn văn bản bạn gõ trong giao diện web. Nó ghi một cấu hình được tạo vào /tmp/openvpn/openvpn.conf và khởi động daemon bằng tệp đó, nên các trường trên giao diện và mọi văn bản trong Additional Config được hợp nhất trước khi OpenVPN nhìn thấy chúng. Nếu bạn gỡ lỗi biểu mẫu thay vì tệp được tạo, bạn đang đọc một ý định chứ không phải đầu vào thực tế. Hãy sao chép tệp đó đến một nơi lâu dài trước khi một lần khởi động lại /tmp xóa nó.

So sánh tệp được tạo với điều bạn định làm, đặc biệt ở chỗ giao diện ghi một chỉ thị mà bạn chưa bao giờ chọn. Một menu thả xuống phát ra tùy chọn lỗi thời thì vô hình trong biểu mẫu và gây chết người cho daemon.

Nếu tệp được tạo trống hoặc không tồn tại, daemon thậm chí chưa tới được bước khởi động, và vấn đề nằm ở phía trước OpenVPN.

OpenVPN 2.5 đã ngừng chấp nhận điều gì

OpenVPN 2.5 đã thay ncp-ciphers bằng data-ciphers, và nâng phiên bản TLS tối thiểu mặc định lên 1.2. Nó cũng thay đổi cách xử lý nén, nên một đối tác đề nghị nén sẽ bị từ chối trừ khi cấu hình cho phép rõ ràng, và nó đánh dấu lỗi thời các tên tùy chọn cũ như ns-cert-type để thay bằng remote-cert-tls. Mỗi thay đổi đó biến một cấu hình từng chạy được thành lỗi phân tích hoặc thương lượng.

Cách lỗi phụ thuộc vào chỉ thị. Một tùy chọn không xác định hoặc đã bị loại bỏ sẽ dừng daemon ngay khi khởi động, đó là listener chết của bạn. Sự không khớp khi thương lượng để daemon chạy tiếp và từ chối máy khách, điều mà từ phía máy khách trông như vấn đề tường lửa.

Hãy đọc lỗi đầu tiên trong nhật ký, không phải lỗi cuối cùng. Quá trình phân tích dừng ở chỉ thị sai đầu tiên, và mọi thứ sau đó chỉ là tiếng ồn của việc tắt.

Các điều kiện tiên quyết riêng cho Broadcom

Trên các bản build Broadcom, thiết bị đường hầm phải tồn tại trước khi daemon dùng được nó. Kiểm tra rằng mô-đun tun đã được nạp và /dev/net/tun có mặt, vì thiếu thiết bị sẽ tạo ra lỗi khởi động không liên quan gì đến chứng chỉ. Điều tương tự áp dụng cho các script phụ mà DD-WRT tạo cho tuyến đường và DNS: nếu thiếu hoặc không chạy được, daemon có thể khởi động và vẫn không hoàn tất cấu hình.

Chạy daemon ở tiền cảnh với độ chi tiết cao hơn trên cấu hình được tạo khi bạn cần thông điệp thật. Chạy ở tiền cảnh in ra lỗi phân tích mà script init đã nuốt mất.

Sau đó khôi phục dịch vụ bình thường, vì daemon ở tiền cảnh và script init sẽ tranh nhau cổng.

Chứng minh listener tồn tại trước khi gỡ lỗi máy khách

Xác nhận tiến trình và socket riêng rẽ: một lệnh cho daemon đang chạy, lệnh khác cho cổng UDP được gắn vào địa chỉ mong đợi. Một tiến trình không có socket nghĩa là nó vẫn đang cấu hình hoặc gắn vào giao diện sai. Cặp này là phép thử hữu ích chính vì một nửa không thể đúng nếu thiếu nửa kia.

Gỡ lỗi phía máy khách chỉ có ý nghĩa sau khi listener tồn tại. Khi đó hãy kiểm tra rằng mã hóa và cài đặt TLS của máy khách khớp với danh sách data-ciphers của máy chủ và phiên bản tối thiểu, và cổng thực sự được chuyển tiếp tới router.

Hãy giữ lại cấu hình được tạo và dòng nhật ký đã chứng minh bản sửa. Bản cập nhật firmware tiếp theo có thể lại thay đổi giá trị mặc định, và chính bản ghi đó biến một lần tái diễn thành kiểm tra năm phút.

Bài viết liên quan