OpenVPN ilk satırı reddediyor mu? Dosya büyük olasılıkla UTF-16

Hata, bir .ovpn dosyasının ilk satırına işaret eder ve client olması gereken yerde karışmış harflere benzeyen bir şey alıntılar. Dosya düzenleyicinizde sorunsuz açılır, ilk satır client okunur ve yönerge tamamen sıradandır. Her iki gözlem de doğrudur, çünkü düzenleyici baytları çözer, istemci ise çözmez. Gördüğünüz şey neredeyse her zaman bir kodlama sorunudur, sözdizimi sorunu değil.

Efsane: düzenleyici size dosyayı gösterir

Bir metin düzenleyici baytları, ya algıladığı ya da tahmin ettiği bir kodlamayla karakterlere çözer. UTF-16'yı tahmin ettiğinde dosya ekranda kusursuz görünür, oysa altındaki baytlar çiftlerdir ve her Latin harfinden sonra bir sıfır baytı gelir. OpenVPN bu baytları karakter olarak okur ve uyumsuzluk, ayrıştırmaya çalıştığı ilk yönergede ortaya çıkar.

Yani görünen satır ile teslim edilen satır iki farklı şeydir. Gördüğünüz garip karakterleri silmek kodlamada değil görünümde bir değişikliktir ve sonraki ayrıştırma da aynı nedenle biraz farklı bir mesajla başarısız olur. Hatanın içindeki belirteci kovalamanın hiçbir yere varmamasının nedeni budur. Baytlar kaynakta yanlıştır ve aşağıdaki her okuyucu aynı bozuk diziyi tahmin eder.

Arızanın belirli biçimini tanımakta yarar var, çünkü kendine özgü bir şekilde tanısaldır. Dosyanın en başındaki bir belirteç, başka makinelerde çalışmış bir profilde, sözcük dağarcığı değil bayt sırası sorusudur.

İlk baytlar gerçekte ne söylüyor

Karakterler yerine baytları okuyun. İki küçük komut bunu saniyeler içinde çözer ve ikisi de dosyayı değiştirebilecek bir uygulamada açmayı gerektirmez:

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

Aradığınız desen, her ikinci baytı sıfır olan bir metnin önüne gelen bir çift başlangıç baytıdır. FF FE UTF-16 little-endian anlamına gelir, FE FF big-endian anlamına gelir ve EF BB BF bayt sırası işaretli UTF-8 anlamına gelir. İşaretsiz sıradan bir UTF-8 dosyası doğrudan ilk harfin baytıyla başlar.

Harfler arasındaki sıfır baytlar asıl ipucudur. UTF-16 little-endian'da client sözcüğü altı yerine on iki bayt kaplar, çünkü her ASCII karakterinden sonra bir sıfır gelir. Bu yapıyı bir düzenleyicinin ekranı size gösteremez ve iki baytlık bir silme onu kaldıramaz.

Burada önemli bir incelik var: OpenVPN'in yapılandırma okuyucusu, 2.6 yapılandırma okuyucusunun gösterdiği gibi, dosyanın başındaki UTF-8 bayt sırası işaretini gerçekten atlar. Bu hoşgörü tam olarak o işarete özgüdür ve harfleri sıfırlarla doldurulmuş bir UTF-16 dosyası için hiçbir şey yapmaz. İki işareti aynı sorun olarak görmek efsanenin ikinci yarısıdır.

Dönüştürme silmek değil, farklı kaydetmektir

Herhangi bir şey yapmadan önce operatörün orijinalinin dokunulmamış bir kopyasını saklayın ve ayrı bir dosyada çalışın. Bir profilde özel anahtar veya hesap malzemesi olabilir, bu yüzden kopya hem geri dönüş yolunuz hem de referansınızdır.

Ardından gerçek bir kodlama dönüştürmesi yapın; ya düzenleyicinin açık kodlama menüsüyle ya da giriş ve çıkış kodlamasını belirten bir dönüştürücüyle:

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

Komutun çıkış durumuna güvenmek yerine sonucu doğrulayın. Dönüştürme her yönergeyi korumalı ve işaretlerinin içindeki her gömülü sertifika veya anahtar bloğunu bayt bayt korumak zorundadır. PEM verilerini yeniden sarmalamak, bir bloğun içindeki satır sonlarını değiştirmek veya dönüştürme sırasında profili yeniden biçimlendirmek eski sorunu çözerken yeni bir sorun yaratır.

İstemciyi veya hizmeti dönüştürülmüş dosyaya yönlendirin ve bildirdiği ilk hataya bakın. Karışmış belirteç gittiyse kodlama işi bitmiştir ve sonrasında başarısız olan her şey başka bir sorudur.

Düzeltilmiş bir kodlamanın düzeltmediği şeyler

Kodlama metnin nasıl okunduğunu belirler; seçeneklerin önünüzdeki istemci için geçerli olup olmadığı hakkında hiçbir şey söylemez. Başka bir uygulama için dışa aktarılmış bir profil temiz ayrıştırılabilir ve yine de çalışan derlemenin desteklemediği bir seçenek ya da argümanı o istemcide başka bir anlama gelen bir yönerge yüzünden reddedilebilir.

O sonraki hatalar kendi incelemesini hak eder: tam yazım, argümanın sözdizimi ve onu kabul eden sürüm. Başarılı bir ayrıştırmayı başarılı bir profil olarak görmeyin.

Üzerinde çalışırken incelemeyi yerel tutun. Herkese açık çevrimiçi dönüştürücüler ve yapıştırılmış hex dökümleri, özel anahtar içerebilecek bir dosya için kötü bir yerdir, çünkü kodlama sorununu düzeltmek kolaydır, sızmış bir anahtarı değil.