OpenVPN verwerp reël een? Die lêer is waarskynlik UTF-16

Die fout wys na die eerste reël van ’n .ovpn-lêer en haal iets aan wat soos deurmekaar letters lyk waar client behoort te staan. Die lêer maak foutloos in jou redigeerder oop, die eerste reël lees client, en die opdrag is heeltemal gewoon. Albei waarnemings is waar, want die redigeerder dekodeer die grepe en die kliënt doen dit nie. Wat jy sien, is byna altyd ’n enkoderingsprobleem, nie ’n sintaksprobleem nie.

Die mite: die redigeerder wys jou die lêer

’n Teksredigeerder dekodeer grepe na karakters met ’n enkodering wat hy óf waarneem óf raai. Wanneer hy UTF-16 raai, lyk die lêer perfek op die skerm terwyl die onderliggende grepe pare is, met ’n nulgreep ná elke Latynse letter. OpenVPN lees daardie grepe as karakters, en die wanverhouding verskyn by die eerste opdrag wat hy probeer ontleed.

Dus is die sigbare reël en die afgelewerde reël twee verskillende dinge. Om die vreemde karakters wat jy kan sien te verwyder, is ’n verandering aan die vertoning, nie aan die enkodering nie, en die volgende ontleding misluk om dieselfde rede met ’n effens ander boodskap. Daarom lei die jaag op die teken in die fout steeds nêrens heen nie. Die grepe is verkeerd by die bron, en elke leser daarna raai dieselfde stukkende reeks.

Die spesifieke vorm van die mislukking is die moeite werd om te herken, want dit is op ’n spesifieke manier diagnosties. ’n Teken heel aan die begin van die lêer, in ’n profiel wat andersins op ander masjiene gewerk het, is ’n vraag oor grepeorde eerder as ’n vraag oor woordeskat.

Wat die eerste grepe werklik sê

Lees die grepe in plaas van die karakters. Twee klein opdragte beslis dit in sekondes, en nie een vereis dat jy die lêer in ’n toepassing oopmaak wat dit kan verander nie:

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

Die patroon waarna jy soek, is ’n paar leidende grepe gevolg deur teks waarin elke tweede greep nul is. FF FE dui UTF-16 little-endian aan, FE FF dui big-endian aan, en EF BB BF dui UTF-8 met ’n grepeordemerk aan. ’n Gewone UTF-8-lêer sonder merk begin direk met die greep van die eerste letter.

Nulgrepe tussen letters is die verklikker. In UTF-16 little-endian beslaan die woord client twaalf grepe eerder as ses, want elke ASCII-karakter word deur ’n nul gevolg. Daardie struktuur is nie iets wat ’n redigeerder se vertoning vir jou kan wys nie, en dit is nie iets wat ’n skrapping van twee grepe kan verwyder nie.

’n Belangrike nuansering lê hier: OpenVPN se konfigurasieleeser slaan wel ’n UTF-8-grepeordemerk aan die begin van ’n lêer oor, soos die 2.6-konfigurasieleeser wys. Daardie verdraagsaamheid geld spesifiek vir daardie merk, en dit doen niks vir ’n UTF-16-lêer waarvan die letters met nulle opgevul is nie. Om die twee merke as dieselfde probleem te behandel, is die tweede helfte van die mite.

Omskakeling is ’n stoor-as, nie ’n verwydering nie

Hou ’n ongerooide kopie van die operateur se oorspronklike voordat jy enigiets doen, en werk op ’n aparte lêer. ’n Profiel kan ’n private sleutel of rekeningmateriaal bevat, so die kopie is beide jou terugrol en jou verwysing.

Voer dan ’n werklike enkoderingomskakeling uit, hetsy deur die redigeerder se eksplisiete enkoderingkieslys of met ’n omskakelaar wat sy invoer- en uitvoerenkodering noem:

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

Verifieer die resultaat eerder as om op die opdrag se uitgangstatus te vertrou. Die omskakeling moet elke opdrag bewaar, en dit moet enige ingebedde sertifikaat- of sleutelblok greep vir greep binne sy merkers bewaar. Om PEM-data te hervou, reëleindes binne ’n blok te verander of die profiel tydens die omskakeling te herformatteer, skep ’n nuwe probleem terwyl die ou een reggemaak word.

Rig die kliënt of diens na die omgeskakelde lêer en kyk na die eerste fout wat dit rapporteer. As die deurmekaar teken weg is, is die enkoderingwerk gedoen en enigiets wat daarna misluk, is ’n ander vraag.

Wat ’n reggemaakte enkodering nie regmaak nie

Enkodering bepaal hoe teks gelees word; dit sê niks oor of die opsies geldig is vir die kliënt voor jou nie. ’n Profiel wat vir ’n ander implementering uitgevoer is, kan skoon ontleed en steeds verwerp word vir ’n opsie wat die lopende bou nie ondersteun nie, of vir ’n opdrag waarvan die argument iets anders in daardie kliënt beteken.

Daardie latere foute verdien hul eie ondersoek: die presiese spelling, die argument-sintaksis en die weergawe wat dit aanvaar. Moenie ’n suksesvolle ontleding as ’n suksesvolle profiel beskou nie.

Hou die ondersoek plaaslik terwyl jy daarmee besig is. Openbare aanlyn-omskakelaars en geplakte hex-dumps is ’n swak plek vir ’n lêer wat ’n private sleutel kan bevat, want die enkoderingprobleem is maklik om reg te maak en ’n gelekte sleutel is nie.