OpenVPN wiist rigel ien ôf? It bestân is wierskynlik UTF-16

De flater wiist nei de earste rigel fan in .ovpn-bestân en sitearret eat dat op trochelkoar smiten letters liket wêr’t client stean moat. It bestân iepenet sûnder problemen yn jo bewurker, de earste rigel lêst client, en de direktive is hiel gewoan. Beide waarnimmings binne wier, om’t de bewurker de bytes dekodearret en de klant dat net docht. Wat jo sjogge is hast altyd in kodearringsoprobleem, gjin syntaksprobleem.

De myte: de bewurker lit jo it bestân sjen

In teksbewurker dekodearret bytes nei tekens mei in kodearring dy’t er óf detektearret óf riedt. As er UTF-16 riedt, sjocht it bestân der perfekt út op it skerm wylst de ûnderlizzende bytes pearen binne, mei in nulbyte nei elke Latynske letter. OpenVPN lêst dy bytes as tekens, en de miskleau komt by de earste direktive dy’t er besiket te ûntlieden.

Sa binne de sichtbere rigel en de levere rigel twa ferskillende dingen. It wiskjen fan de frjemde tekens dy’t jo sjogge is in feroaring oan ’e werjefte, net oan ’e kodearring, en de folgjende ûntlieding mislearret om deselde reden mei in pear oare berjocht. Dêrom liedt it jeien op it teken yn ’e flater hieltyd nearne. De bytes binne ferkeard by de boarne, en elke lêzer dêrnei riedt deselde stikken sekwinsje.

De spesifike foarm fan ’e mislearring is it wurdich om te erkennen, want it is op in spesifike manier diagnostysk. In teken hiel oan it begjin fan it bestân, yn in profyl dat oars op oare masines wurke hat, is in fraach oer bytfolchoarder ynstee fan in fraach oer wurdskat.

Wat de earste bytes eins sizze

Lês de bytes ynstee fan ’e tekens. Twa lytse opdrachten beslisse it yn sekonden, en gjin fan beide freget om it bestân te iepenjen yn in applikaasje dy’t it feroarje kin:

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

It patroan dat jo sykje is in pear liedende bytes folge troch tekst wêryn’t elke twadde byte nul is. FF FE tsjut UTF-16 little-endian oan, FE FF tsjut big-endian oan, en EF BB BF tsjut UTF-8 mei in bytfolchoardermerk oan. In gewoan UTF-8-bestân sûnder merk begjint direkt mei de byte fan ’e earste letter.

Nulbytes tusken letters binne de oanwizing. Yn UTF-16 little-endian beslacht it wurd client tolve bytes ynstee fan seis, om’t efter elk ASCII-teken in nul komt. Dy struktuer kin it skerm fan in bewurker jo net sjen litte, en it is net eat dat it wiskjen fan twa bytes fuorthelje kin.

Hjir sit in wichtige nuânse: de konfiguraasjelêzer fan OpenVPN slacht yndie in UTF-8-bytfolchoardermerk oan it begjin fan in bestân oer, sa’t de konfiguraasjelêzer 2.6 sjen lit. Dy tolerânsje jildt spesifyk foar dy merk, en hy docht neat foar in UTF-16-bestân waans letters mei nullen opskode binne. De twa merken as itselde probleem behannelje is de twadde helte fan ’e myte.

Konvertearjen is bewarje-as, net wiskje

Hâld in ûnoantaaste kopy fan it orizjineel fan ’e operator foardat jo eat dogge, en wurkje op in apart bestân. In profyl kin in partikuliere kaai of akkountmateriaal befetsje, dus is de kopy sawol jo weromrinnen as jo referinsje.

Doch dan in echte kodearringskonverzje, itsij fia it eksplisite kodearringsmenu fan ’e bewurker, itsij mei in konverter dy’t syn ynfier- en útfierkodearring neamt:

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

Ferifiearje it resultaat ynstee fan op ’e útgongsstatus fan ’e opdracht te fertrouwen. De konverzje heart elke direktive te behâlden, en hy moat elke ynboude sertifikaat- of kaaiblok byte foar byte binnen syn markearrings behâlde. PEM-gegevens op ’e nij ynpakke, rigeleinen binnen in blok feroarje of it profyl by de konverzje op ’e nij opmeitsje skept in nij probleem wylst it âlde reparearre wurdt.

Rjochtsje de klant of tsjinst op it konvertearre bestân en sjoch nei de earste flater dy’t er rapportearret. As it trochelkoar teken fuort is, is it kodearringswurk dien en is alles wat dêrnei mislearret in oare fraach.

Wat in reparearre kodearring net reparearret

Kodearring bepaalt hoe’t tekst lêzen wurdt; it seit neat oer oft de opsjes jildich binne foar de klant foar jo. In profyl dat foar in oare ymplemintaasje eksportearre is, kin skjin ûntliend wurde en dochs ôfwiisd wurde foar in opsje dy’t de rinnende build net stipet, of foar in direktive waans argumint yn dy klant eat oars betsjut.

Dy lettere flaters fertsjinje har eigen ûndersyk: de krekte stavering, de syntaksis fan it argumint en de ferzje dy’t it akseptearret. Beskôgje in slagge ûntlieding net as in slagge profyl.

Hâld it ûndersyk lokaal wylst jo dermei dwaande binne. Iepenbiere online-konverters en plakte hex-dumps binne in min plak foar in bestân dat in partikuliere kaai befetsje kin, om’t it kodearringsoprobleem maklik te reparearjen is en in lekte kaai net.