Hvorfor OpenVPN på Windows siger ca: en sti uden citationstegn, ikke et dårligt certifikat

OpenVPN starter ikke, og fejlmeddelelsen peger på en linje, der ser fin ud: Unrecognized option or missing or extra parameter(s) in office.ovpn:42: ca. Certifikatet er ikke ændret, filen åbner i en editor, og intet ved stien ser forkert ud. Parseren indvender ikke mod indstillingens navn; den indvender mod, hvor mange argumenter der kom med det. Fire kontroller løser næsten hvert eneste tilfælde, og de er værd at køre i rækkefølge efter omkostning.

Hvorfor parseren bebrejder indstillingen

Hver konfigurationslinje deles på mellemrum og på citationstegn, før nogen indstilling ser den. En værdi med et mellemrum ankommer derfor som flere argumenter, medmindre den er pakket ind, og den indstilling, der ejede linjen, rapporterer uoverensstemmelsen. På Windows gør standardinstallationsmappen det sikkert, fordi C:\Program Files af konstruktion ligger midt i stien. Certifikatet åbnes aldrig i denne fejl, så en kontrol af, om filen findes, beviser intet nyttigt.

Det rapporterede linjenummer er som regel rigtigt, og den rapporterede indstilling er den, der brugte linjen. Når den nævnte indstilling er en, du ved, du aldrig har skrevet, så læs linjen ovenover, fordi et tabt citationstegn i en tidligere blok flytter parsingen. Sådan ender en certifikatblok med at få skylden for et argumentantal.

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

Sæt citationstegn om hver sti med et mellemrum

Et par dobbelte citationstegn om værdien er hele reparationen, og skråstreger fremad accepteres på Windows, så escaping bliver aldrig en del af problemet. Ret hver stiindstilling i samme gennemløb, fordi parseren stopper ved den første fejl, og den næste venter blot på den næste genstart. Sættet omfatter normalt 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"

En søgning efter mappenavnet finder hver forekomst hurtigere end at læse filen. Kør den, før du redigerer noget, så listen er komplet:

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

At flytte profilen til en sti uden mellemrum er et gyldigt alternativ, og det er kun gyldigt, hvis hver sti flytter med. En halvt migreret profil gengiver den samme fejl med et andet filnavn, hvilket er sværere at opdage, fordi meddelelsen nu peger på en sti, du netop har oprettet. Vælg én tilgang, og gør den færdig.

Gendan tilstandserklæringen før certifikaterne

Den anden almindelige årsag giver en anden meddelelse med den samme spildte eftermiddag. En klientprofil skal erklære sin tilstand nær toppen, og den erklæring er let at miste, når kun certifikatblokkene indsættes i en ny fil. Uden den læser OpenVPN filen med et andet sæt standardværdier, og skaden viser sig meget senere som en konflikt mellem indstillinger eller en mislykket login. Den manglende linje er billig at kontrollere og dyr at glemme.

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

Hold én direktiv per linje, mens du er der. Sammenføjede linjer giver præcis argumentantal-fejlen fra det første afsnit, og den rapporterede linje ser rimelig ud, fordi sammenføjningen skete, hvor editoren ombrydede teksten. Læs den rå linje, ikke den viste.

Kodningsskade ser ud som et indstillingsnavn

En fil, der blev gemt som UTF-16 med byteordensmærke, skjuler sin første indstilling for parseren, og løse bytes kan hænge sig på indstillingens navn i meddelelsen. Gem filen som UTF-8 uden byteordensmærke, åbn den derefter igen, og bekræft, at det første tegn er et normalt bogstav. Editorer, PowerShell-omdirigering og tekst indsat fra et chatvindue ændrer alle kodningen uden at spørge.

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

Et byteordensmærke vises som indledende markørbytes før enhver tekst, og at slette disse tegn i hånden er et tabende træk, fordi editoren skriver dem tilbage ved næste gem. Gem i stedet filen igen med en eksplicit kodning. Linjeafslutninger er mere overbærende, men en fil uden ny linje til sidst kan stadig flette den sidste direktiv ind i den foregående efter en redigering.

Hvilken kontrol skal køres først, og hvorfor

Begynd med kodningen, fordi den koster én kommando og ugyldiggør enhver anden læsning af filen. Så citationstegnene, derefter tilstandserklæringen og de andre obligatoriske direktiver, og først efter dem certifikaterne, nøglerne og adgangsoplysningerne. At arbejde i den rækkefølge holder hvert skridt reversibelt, fordi et certifikat, der byttes for at rette et citationstegnsproblem, efterlader en fungerende installation med en ny fejl, der er to redigeringer fra originalen. Rækkefølgen betyder mere end de enkelte kontroller.

Behold en urørt kopi af filen, som operatøren afleverede den. Hvis en senere redigering ødelægger den, viser en diff mod den kopi, om et citationstegn, en ny linje eller en markørbyte har flyttet sig, hvilket er hurtigere end at læse fejlen igen. Indstillingsreferencen for hver direktiv findes i OpenVPN-manualen for den installerede version.