Varför OpenVPN i Windows säger ca: en sökväg utan citattecken, inte ett dåligt certifikat

OpenVPN startar inte, och felmeddelandet pekar på en rad som ser helt riktig ut: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. Certifikatet har inte ändrats, filen öppnas i en editor, och inget i sökvägen ser fel ut. Parsern invänder inte mot alternativets namn; den invänder mot hur många argument som kom med det. Fyra kontroller löser nästan varje sådant fall, och de är värda att köra i kostnadsordning.

Varför parsern skyller på alternativet

Varje konfigurationsrad delas på blanksteg och på citattecken innan något alternativ ser den. Ett värde med ett blanksteg kommer därför som flera argument om det inte är inneslutet, och alternativet som ägde raden rapporterar avvikelsen. I Windows gör standardinstallationsmappen det säkert, eftersom C:\Program Files av konstruktionen ligger mitt i sökvägen. Certifikatet öppnas aldrig i detta fel, så en kontroll av om filen finns bevisar ingenting användbart.

Det rapporterade radnumret stämmer oftast, och det rapporterade alternativet är det som förbrukade raden. När alternativet som nämns är ett du vet att du aldrig har skrivit, läs raden ovanför, eftersom ett tappat citattecken i ett tidigare block förskjuter parsningen. Så blir ett certifikatblock till slut beskylld för antalet argument.

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

Sätt citattecken runt varje sökväg med blanksteg

Ett par dubbla citattecken runt värdet är hela reparationen, och snedstreck godtas i Windows, så escapning blir aldrig en del av problemet. Rätta alla sökvägsalternativ i samma genomgång, eftersom parsern stannar vid första felet och nästa bara väntar på nästa omstart. Uppsättningen omfattar oftast ca, cert, key, tls-auth och auth-user-pass.

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"

En sökning på mappnamnet hittar varje förekomst snabbare än att läsa filen. Kör den innan du redigerar något, så att listan blir komplett:

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

Att flytta profilen till en sökväg utan blanksteg är ett giltigt alternativ, och det är bara giltigt om varje sökväg flyttar med. En halvmigrerad profil återger samma fel med ett annat filnamn, vilket är svårare att upptäcka eftersom meddelandet nu pekar på en sökväg du just skapade. Välj ett tillvägagångssätt och slutför det.

Återställ lägesdeklarationen före certifikaten

Den andra vanliga orsaken ger ett annat meddelande med samma bortkastade eftermiddag. En klientprofil måste deklarera sitt läge nära toppen, och den deklarationen tappas lätt när bara certifikatblocken klistras in i en ny fil. Utan den läser OpenVPN filen med en annan uppsättning standardvärden, och skadan visar sig mycket senare som en konflikt mellan alternativ eller en misslyckad inloggning. Den saknade raden är billig att kontrollera och dyr att glömma.

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

Håll en direktiv per rad medan du är där. Sammanfogade rader ger exakt argumentantalsfelet från första avsnittet, och den rapporterade raden verkar rimlig eftersom sammanfogningen skedde där editorn bröt texten. Läs den råa raden, inte den visade.

Kodningsskada ser ut som ett alternativnamn

En fil som sparades som UTF-16 med byteordningsmärke döljer sitt första alternativ för parsern, och lösa byte kan fastna på alternativnamnet i meddelandet. Spara filen som UTF-8 utan byteordningsmärke, öppna den sedan igen och bekräfta att det första tecknet är en vanlig bokstav. Editorer, PowerShell-omdirigering och text inklistrad från ett chattfönster ändrar alla kodningen utan att fråga.

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

Ett byteordningsmärke visas som inledande markeringsbyte före all text, och att radera dessa tecken för hand är ett förlorande drag eftersom editorn skriver tillbaka dem vid nästa sparning. Spara i stället filen igen med en uttrycklig kodning. Radslut är mer förlåtande, men en fil utan ny rad i slutet kan fortfarande slå samman den sista direktiven med den föregående efter en redigering.

Vilken kontroll först, och varför

Börja med kodningen, eftersom den kostar ett kommando och ogiltigförklarar varje annan läsning av filen. Sedan citattecknen, därefter lägesdeklarationen och de andra obligatoriska direktiven, och först efter dem certifikaten, nycklarna och inloggningsuppgifterna. Att arbeta i den ordningen håller varje steg reversibelt, eftersom ett certifikat som byts ut för att rätta ett citatteckensproblem lämnar en fungerande installation med ett nytt fel som är två redigeringar från originalet. Ordningen betyder mer än de enskilda kontrollerna.

Behåll en orörd kopia av filen så som operatören levererade den. Om en senare redigering förstör den visar en skillnad mot den kopian om ett citattecken, en ny rad eller en markeringsbyte har flyttats, vilket är snabbare än att läsa felet igen. Alternativreferensen för varje direktiv finns i OpenVPN-handboken för den installerade versionen.