Hvorfor OpenVPN på Windows sier ca: en sti uten anførselstegn, ikke et dårlig sertifikat

OpenVPN starter ikke, og feilmeldingen peker på en linje som ser helt riktig ut: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. Sertifikatet er ikke endret, filen åpnes i en editor, og ingenting ved stien ser galt ut. Parseren innvender ikke mot navnet på valget; den innvender mot hvor mange argumenter som kom med det. Fire kontroller løser nesten hvert eneste tilfelle, og de er verdt å kjøre i kostnadsrekkefølge.

Hvorfor parseren klandrer valget

Hver konfigurasjonslinje deles på mellomrom og på anførselstegn før noe valg ser den. En verdi med et mellomrom kommer derfor som flere argumenter med mindre den er pakket inn, og valget som eide linjen rapporterer avviket. På Windows gjør standard installasjonsmappe det sikkert, fordi C:\Program Files av konstruksjon ligger midt i stien. Sertifikatet åpnes aldri i denne feilen, så en sjekk av om filen finnes beviser ingenting nyttig.

Det rapporterte linjenummeret er som regel riktig, og det rapporterte valget er det som brukte linjen. Når valget som nevnes er et du vet du aldri har skrevet, les linjen over, fordi et tapt anførselstegn i en tidligere blokk forskyver parsingen. Slik ender en sertifikatblokk opp med å få skylden for et argumentantall.

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

Sett anførselstegn rundt hver sti med et mellomrom

Ett par doble anførselstegn rundt verdien er hele reparasjonen, og skråstreker godtas på Windows, så escaping blir aldri en del av problemet. Rett alle stivalg i samme gjennomgang, fordi parseren stopper ved første feil og neste bare venter på neste omstart. Settet omfatter vanligvis ca, cert, key, tls-auth og 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"

Et søk etter mappenavnet finner hver forekomst raskere enn å lese filen. Kjør det før du redigerer noe, slik at listen er komplett:

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

Å flytte profilen til en sti uten mellomrom er et gyldig alternativ, og det er bare gyldig hvis hver sti flytter med. En halvveis migrert profil gjengir samme feil med et annet filnavn, noe som er vanskeligere å oppdage fordi meldingen nå peker på en sti du nettopp opprettet. Velg én tilnærming og fullfør den.

Gjenopprett modusdeklarasjonen før sertifikatene

Den andre vanlige årsaken gir en annen melding med samme bortkastede ettermiddag. En klientprofil må deklarere modusen sin nær toppen, og den deklarasjonen er lett å miste når bare sertifikatblokkene limes inn i en ny fil. Uten den leser OpenVPN filen med et annet sett standardverdier, og skaden viser seg mye senere som konflikt mellom valg eller mislykket pålogging. Den manglende linjen er billig å kontrollere og dyr å glemme.

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

Hold én direktiv per linje mens du er der. Sammenføyde linjer gir nøyaktig argumentantall-feilen fra første del, og den rapporterte linjen virker rimelig fordi sammenføyingen skjedde der editoren brøt teksten. Les den rå linjen, ikke den viste.

Kodingsskade ser ut som et valgnavn

En fil som ble lagret som UTF-16 med byteordensmerke, skjuler sitt første valg for parseren, og løse bytes kan henge seg på valgnavnet i meldingen. Lagre filen som UTF-8 uten byteordensmerke, åpne den så igjen og bekreft at det første tegnet er en vanlig bokstav. Editorer, PowerShell-omdirigering og tekst limt inn fra et chatvindu endrer alle kodingen uten å spørre.

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

Et byteordensmerke vises som ledende markeringsbytes før all tekst, og å slette disse tegnene for hånd er et tapende trekk fordi editoren skriver dem tilbake ved neste lagring. Lagre i stedet filen på nytt med en eksplisitt koding. Linjeslutt er mer overbærende, men en fil uten ny linje til slutt kan fortsatt slå sammen den siste direktiven med den forrige etter en redigering.

Hvilken kontroll først, og hvorfor

Begynn med kodingen, fordi den koster én kommando og ugyldiggjør enhver annen lesing av filen. Så anførselstegnene, deretter modusdeklarasjonen og de andre påkrevde direktivene, og først etter dem sertifikatene, nøklene og påloggingsdetaljene. Å arbeide i den rekkefølgen holder hvert steg reversibelt, fordi et sertifikat som byttes for å rette et anførselstegn-problem etterlater en fungerende installasjon med en ny feil som er to redigeringer fra originalen. Rekkefølgen betyr mer enn de enkelte kontrollene.

Ta vare på en urørt kopi av filen slik operatøren leverte den. Hvis en senere redigering ødelegger den, viser en diff mot den kopien om et anførselstegn, en ny linje eller en markeringsbyte har flyttet seg, noe som er raskere enn å lese feilen på nytt. Valgreferansen for hver direktiv står i OpenVPN-håndboken for den installerte versjonen.