OpenVPN respinge prima linie? Fișierul este probabil UTF-16

Eroarea indică prima linie a unui fișier .ovpn și citează ceva ce arată ca litere încurcate acolo unde ar trebui să fie client. Fișierul se deschide fără probleme în editorul dvs., prima linie citește client, iar directiva este complet obișnuită. Ambele observații sunt adevărate, pentru că editorul decodează octeții, iar clientul nu. Ceea ce vedeți este aproape întotdeauna o problemă de codificare, nu o problemă de sintaxă.

Mitul: editorul vă arată fișierul

Un editor de text decodează octeți în caractere folosind o codificare pe care o detectează sau o ghicește. Când ghicește UTF-16, fișierul arată perfect pe ecran în timp ce octeții de dedesubt sunt perechi, cu un octet zero după fiecare literă latină. OpenVPN citește acei octeți ca caractere, iar nepotrivirea apare la prima directivă pe care încearcă să o analizeze.

Deci linia vizibilă și linia livrată sunt două lucruri diferite. Ștergerea caracterelor ciudate pe care le vedeți este o schimbare în afișare, nu în codificare, iar analiza următoare eșuează din același motiv cu un mesaj ușor diferit. De aceea goana după simbolul din eroare nu duce niciodată nicăieri. Octeții sunt greșiți la sursă, iar fiecare cititor din aval ghicește aceeași secvență stricată.

Merită recunoscută forma concretă a eșecului, pentru că este diagnostică într-un mod specific. Un simbol chiar la începutul fișierului, într-un profil care altfel a funcționat pe alte mașini, este o chestiune de ordine a octeților și nu de vocabular.

Ce spun de fapt primii octeți

Citiți octeții, nu caracterele. Două comenzi mici lămuresc totul în câteva secunde și niciuna nu cere deschiderea fișierului într-o aplicație care l-ar putea modifica:

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

Modelul pe care îl căutați este o pereche de octeți inițiali urmată de text în care fiecare al doilea octet este zero. FF FE marchează UTF-16 little-endian, FE FF marchează big-endian, iar EF BB BF marchează UTF-8 cu marcaj de ordine a octeților. Un fișier UTF-8 obișnuit fără marcaj începe direct cu octetul primei litere.

Octeții zero dintre litere sunt indiciul. În UTF-16 little-endian cuvântul client ocupă doisprezece octeți în loc de șase, pentru că fiecare caracter ASCII este urmat de un zero. Acea structură nu este ceva ce afișajul unui editor vă poate arăta și nu este ceva ce o ștergere de doi octeți poate elimina.

Aici este o nuanță importantă: cititorul de configurație al OpenVPN sare într-adevăr peste un marcaj de ordine a octeților UTF-8 la începutul fișierului, cum arată cititorul de configurație 2.6. Toleranța aceea este specifică acelui marcaj și nu face nimic pentru un fișier UTF-16 ale cărui litere sunt umplute cu zerouri. Tratarea celor două marcaje ca aceeași problemă este a doua jumătate a mitului.

Convertirea este salvare ca, nu ștergere

Păstrați o copie neatinsă a originalului operatorului înainte de a face orice și lucrați pe un fișier separat. Un profil poate conține o cheie privată sau material de cont, așa că copia este atât revenirea, cât și referința dvs.

Apoi faceți o conversie reală a codificării, fie prin meniul explicit de codificare al editorului, fie cu un convertor care își declară codificarea de intrare și de ieșire:

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

Verificați rezultatul în loc să vă bazați pe starea de ieșire a comenzii. Conversia ar trebui să păstreze fiecare directivă și trebuie să păstreze orice bloc de certificat sau cheie încorporat octet cu octet în interiorul marcajelor sale. Rearanjarea datelor PEM, schimbarea terminațiilor de linie într-un bloc sau reformatarea profilului în timpul conversiei creează o problemă nouă în timp ce o rezolvă pe cea veche.

Îndreptați clientul sau serviciul spre fișierul convertit și uitați-vă la prima eroare pe care o raportează. Dacă simbolul încurcat a dispărut, munca de codificare s-a terminat, iar orice eșuează după aceea este o altă chestiune.

Ce nu repară o codificare reparată

Codificarea determină cum este citit textul; nu spune nimic despre dacă opțiunile sunt valide pentru clientul din fața dvs. Un profil exportat pentru altă implementare poate fi analizat curat și totuși respins din cauza unei opțiuni pe care versiunea care rulează nu o acceptă, sau a unei directive al cărei argument înseamnă altceva în acel client.

Acele erori ulterioare merită propria investigație: ortografia exactă, sintaxa argumentului și versiunea care îl acceptă. Nu tratați o analiză reușită ca pe un profil reușit.

Țineți investigația locală cât timp vă ocupați de ea. Convertizoarele publice online și dump-urile hex lipite sunt un loc prost pentru un fișier care poate conține o cheie privată, pentru că problema de codificare este ușor de reparat, iar o cheie scursă nu.