OpenVPN từ chối dòng đầu tiên? Tệp có lẽ là UTF-16

Lỗi chỉ vào dòng đầu tiên của tệp .ovpn và trích dẫn thứ gì đó trông như những chữ cái bị xáo trộn ở nơi đáng lẽ phải là client. Tệp mở bình thường trong trình soạn thảo của bạn, dòng đầu tiên đọc là client, và chỉ thị hoàn toàn bình thường. Cả hai quan sát đều đúng, vì trình soạn thảo giải mã các byte còn ứng dụng khách thì không. Điều bạn đang thấy gần như luôn là vấn đề mã hóa, không phải vấn đề cú pháp.

Huyền thoại: trình soạn thảo cho bạn thấy tệp

Trình soạn thảo văn bản giải mã byte thành ký tự bằng một kiểu mã hóa mà nó phát hiện hoặc đoán ra. Khi đoán là UTF-16, tệp trông hoàn hảo trên màn hình trong khi các byte bên dưới là từng cặp, với một byte không sau mỗi chữ cái Latinh. OpenVPN đọc những byte đó như ký tự, và sự không khớp xuất hiện ở chỉ thị đầu tiên mà nó cố phân tích.

Vậy nên dòng nhìn thấy và dòng được giao là hai thứ khác nhau. Xóa những ký tự lạ bạn thấy là thay đổi cách hiển thị, không phải mã hóa, và lần phân tích sau thất bại vì cùng lý do với thông báo hơi khác. Đó là lý do việc đuổi theo token trong lỗi không bao giờ dẫn tới đâu. Các byte sai ngay từ nguồn, và mọi trình đọc phía sau đều đoán cùng một chuỗi hỏng.

Hình dạng cụ thể của thất bại đáng được nhận ra, vì nó mang tính chẩn đoán theo một cách riêng. Một token ở ngay đầu tệp, trong một hồ sơ vốn đã chạy trên máy khác, là câu hỏi về thứ tự byte chứ không phải về từ vựng.

Các byte đầu thực sự nói gì

Hãy đọc byte thay vì ký tự. Hai lệnh nhỏ giải quyết việc này trong vài giây, và không lệnh nào đòi mở tệp trong một ứng dụng có thể làm thay đổi nó:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

Mẫu bạn đang tìm là một cặp byte mở đầu, theo sau là văn bản trong đó mỗi byte thứ hai là không. FF FE biểu thị UTF-16 little-endian, FE FF biểu thị big-endian, và EF BB BF biểu thị UTF-8 có dấu thứ tự byte. Một tệp UTF-8 thông thường không có dấu sẽ bắt đầu trực tiếp bằng byte của chữ cái đầu tiên.

Các byte không nằm giữa các chữ cái chính là manh mối. Trong UTF-16 little-endian, từ client chiếm mười hai byte thay vì sáu, vì mỗi ký tự ASCII được theo sau bởi một số không. Cấu trúc đó màn hình trình soạn thảo không thể cho bạn thấy, và việc xóa hai byte cũng không thể loại bỏ nó.

Ở đây có một sắc thái quan trọng: trình đọc cấu hình của OpenVPN thực sự bỏ qua dấu thứ tự byte UTF-8 ở đầu tệp, như trình đọc cấu hình 2.6 cho thấy. Sự khoan dung đó chỉ dành riêng cho dấu đó, và nó không làm gì cho một tệp UTF-16 có các chữ cái được đệm bằng số không. Coi hai dấu là cùng một vấn đề chính là nửa sau của huyền thoại.

Chuyển đổi là lưu thành, không phải xóa

Hãy giữ một bản sao nguyên vẹn của bản gốc từ người vận hành trước khi làm bất cứ điều gì, và làm việc trên một tệp riêng. Hồ sơ có thể chứa khóa riêng hoặc dữ liệu tài khoản, nên bản sao vừa là đường lùi vừa là tài liệu tham chiếu của bạn.

Sau đó thực hiện chuyển đổi mã hóa thật sự, hoặc qua menu mã hóa rõ ràng của trình soạn thảo, hoặc bằng một công cụ chuyển đổi nêu rõ mã hóa đầu vào và đầu ra:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

Hãy kiểm chứng kết quả thay vì tin vào mã thoát của lệnh. Việc chuyển đổi phải giữ nguyên mọi chỉ thị, và phải giữ nguyên từng khối chứng chỉ hoặc khóa nhúng đúng từng byte bên trong các dấu của nó. Việc bọc lại dữ liệu PEM, thay đổi kết thúc dòng bên trong một khối hoặc định dạng lại hồ sơ trong khi chuyển đổi sẽ tạo ra vấn đề mới trong lúc sửa vấn đề cũ.

Trỏ ứng dụng khách hoặc dịch vụ vào tệp đã chuyển đổi và xem lỗi đầu tiên mà nó báo. Nếu token bị xáo trộn đã biến mất, công việc mã hóa đã xong, và bất cứ điều gì thất bại sau đó là một câu hỏi khác.

Điều mà mã hóa đã sửa không sửa được

Mã hóa quyết định văn bản được đọc như thế nào; nó không nói gì về việc các tùy chọn có hợp lệ với ứng dụng khách trước mặt bạn hay không. Một hồ sơ được xuất cho một cách hiện thực khác có thể phân tích sạch sẽ mà vẫn bị từ chối vì một tùy chọn mà bản dựng đang chạy không hỗ trợ, hoặc vì một chỉ thị mà đối số của nó mang nghĩa khác trong ứng dụng khách đó.

Những lỗi về sau đó đáng được điều tra riêng: cách viết chính xác, cú pháp của đối số và phiên bản chấp nhận nó. Đừng coi một lần phân tích thành công là một hồ sơ thành công.

Hãy giữ việc điều tra trong nội bộ khi bạn làm việc đó. Các công cụ chuyển đổi trực tuyến công khai và các bản kết xuất hex dán vào là nơi tồi để đặt một tệp có thể chứa khóa riêng, vì vấn đề mã hóa dễ sửa còn khóa bị lộ thì không.