Waarom OpenVPN op Windows ’ca’ sê: ’n pad sonder aanhalingstekens, nie ’n slegte sertifikaat nie

OpenVPN begin nie, en die foutboodskap wys na ’n reël wat heeltemal reg lyk: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. Die sertifikaat het nie verander nie, die lêer open in ’n redigeerder, en niks aan die pad lyk verkeerd nie. Die ontleder het nie beswaar teen die opsienaam nie; hy het beswaar teen hoeveel argumente saam met dit aangekom het. Vier kontroles los byna elke geval hiervan op, en dit is die moeite werd om hulle in kostevolgorde te doen.

Waarom die ontleder die opsie blameer

Elke konfigurasie-reël word op witruimte en op aanhalingstekens verdeel voordat ’n opsie dit ooit sien. ’n Waarde wat ’n spasie bevat, kom dus as verskeie argumente aan tensy dit omhul is, en die opsie wat die reël besit het, rapporteer die wanverhouding. Op Windows maak die verstekinstalleergids dit seker, want C:\Program Files sit per konstruksie in die middel van die pad. Die sertifikaat word in hierdie fout nooit oopgemaak nie, so om te kyk of die lêer bestaan, bewys niks nuttigs nie.

Die gerapporteerde reëlnommer is gewoonlik reg, en die gerapporteerde opsie is die een wat die reël verbruik het. Wanneer die genoemde opsie een is wat jy weet jy het nooit geskryf nie, lees die reël bokant dit, want ’n aanhalingsteken wat in ’n vroeëre blok verlore gegaan het, verskuif die ontleding. Dis hoe ’n sertifikaatblok uiteindelik geblameer word vir ’n argumenttelling.

ca C:\Program Files\OpenVPN\config\office-ca.crt

Plaas aanhalingstekens om elke pad met ’n spasie

Een paar dubbele aanhalingstekens om die waarde is die hele herstelling, en voorwaartse skuinsstrepe word op Windows aanvaar, so ontsnapping word nooit deel van die probleem nie. Regstel elke padopsie in dieselfde deurgang, want die ontleder stop by die eerste fout en die volgende een wag bloot vir die volgende herbegin. Die stel sluit gewoonlik ca, cert, key, tls-auth en auth-user-pass in.

ca "C:/Program Files/OpenVPN/config/office-ca.crt"
cert "C:/Program Files/OpenVPN/config/office.crt"
key "C:/Program Files/OpenVPN/config/office.key"

’n Soektog na die gidsnaam vind elke voorkoms vinniger as om die lêer te lees. Voer dit uit voordat jy enigiets redigeer, sodat die lys volledig is:

Select-String -Path .\office.ovpn -Pattern 'Program Files'

Om die profiel na ’n pad sonder spasies te skuif, is ’n geldige alternatief, en dit is net geldig as elke pad saam skuif. ’n Half-gemigreerde profiel reproduseer dieselfde fout met ’n ander lêernaam, wat moeiliker raak om raak te sien omdat die boodskap nou na ’n pad wys wat jy pas geskep het. Kies een benadering en maak dit klaar.

Herwin die modusverklaring voor die sertifikate

Die tweede algemene oorsaak lewer ’n ander boodskap met dieselfde vermorste middag. ’n Kliëntprofiel moet sy modus naby die bokant verklaar, en daardie verklaring is maklik om te verloor wanneer net die sertifikaatblokke in ’n nuwe lêer geplak word. Sonder dit lees OpenVPN die lêer met ’n ander stel verstekke, en die skade verskyn baie later as ’n konflik tussen opsies of ’n aanmeldingsfout. Die ontbrekende reël is goedkoop om te kontroleer en duur om te vergeet.

client
dev tun
proto udp
remote vpn.example.net 1194

Hou een riglyn per reël terwyl jy daar is. Saamgevoegde reëls lewer presies die argumenttelling-fout uit die eerste afdeling, en die gerapporteerde reël lyk redelik omdat die samevoeging gebeur het waar die redigeerder die teks toegedraai het. Lees die rou reël eerder as die weergegewe een.

Enkoderingskade lyk soos ’n opsienaam

’n Lêer wat as UTF-16 gestoor is, kompleet met ’n greeporde-merk, versteek sy eerste opsie vir die ontleder, en los grepe kan aan die opsienaam in die boodskap vasklou. Stoor die lêer as UTF-8 sonder ’n greeporde-merk, heropen dit dan en bevestig dat die eerste karakter ’n normale letter is. Redigeerders, PowerShell-herleiding en teks wat uit ’n kletsvenster geplak is, verander almal die enkodering sonder om te vra.

Format-Hex .\office.ovpn | Select-Object -First 1

’n Greeporde-merk verskyn as voorste merkgrepe voor enige teks, en om daardie karakters met die hand te verwyder is ’n verlore stap omdat die redigeerder hulle by die volgende stoor weer terugskryf. Stoor die lêer eerder weer met ’n eksplisiete enkodering. Reël-eindes is meer verdraagsaam, maar ’n lêer sonder ’n nuwe reël aan die einde kan die laaste riglyn na ’n wysiging steeds in die vorige een saamsmelt.

Watter kontrole eerste, en waarom

Begin met die enkodering, want dit kos een opdrag en maak elke ander lesing van die lêer ongeldig. Dan die aanhalingstekens, dan die modusverklaring en die ander verpligte riglyne, en eers daarna die sertifikate, sleutels en geloofsbriewe. Om in daardie orde te werk, hou elke stap omkeerbaar, want ’n sertifikaat wat omgeruil is om ’n aanhalingstekenprobleem reg te maak, laat ’n werkende installasie met ’n nuwe fout wat twee wysigings van die oorspronklike af is. Die orde maak meer saak as die individuele kontroles.

Hou ’n onaangeraakte kopie van die lêer soos die operateur dit verskeep het. As ’n latere wysiging dit breek, wys ’n diff teen daardie kopie of ’n aanhalingsteken, ’n nuwe reël of ’n merkgreep geskuif het, wat vinniger is as om die fout weer te lees. Die opsieverwysing vir elke riglyn is in die OpenVPN-handleiding vir die geïnstalleerde weergawe.