Ett OpenVPN-direktiv per rad, och varför radbrytning ljuger
En mjukt radbruten skärm är inte en ny rad i filen. Kontrollera de verkliga radbrytningarna innan du ersätter ett felaktigt avsnitt med en främmandes mall.
En profil som tidigare startade misslyckas nu med ett alternativfel, och raden som parsern citerar ser helt rimlig ut på skärmen. Det är fällan: en konfigurationsfil är en lista av fysiska rader, var och en med ett alternativnyckelord och dess argument, och en lång rad som radbryts av en editor ser identisk ut med två rader tills man tittar på byten. Inget av nätverket, certifikatet eller tunneln är inblandat i den här typen av fel. Två rader som ser identiska ut på skärmen kan skilja sig med en enda byte.
Gå igenom kontrollerna nedan i ordning och stanna vid den första som misslyckas. Var och en är billigare än nästa, och var och en utesluter en annan förklaring.
En rad, ett direktiv
Parsern läser en rad, tar det första ordet som alternativet och behandlar resten som det alternativets argument. En rad som cert server.crt port 1194 är alltså inte två instruktioner i följd. Det är ett cert-alternativ med tre argument, och det tredje är inte ett filnamn som alternativet accepterar. Att läsa felet som en saknad radbrytning är rätt; att läsa det som ett saknat direktiv är det inte.
# malformed: one option, three arguments
cert server.crt port 1194
# intended: two options, one argument each
cert server.crt
port 1194
De två rättade raderna är ett fragment, inte en konfiguration. De finns för att visa var gränsen hör hemma. Varje vanligt direktiv i en profil följer samma regel, och en rad som sammanfogar två av dem ger antingen ett argumentfel eller ett värde som alternativet inte förväntade sig.
Bevisa att radbrytningen är verklig
Editorer radbryter för visning. En del infogar också hårda brytningar när du klistrar in, andra inte, så samma visuella resultat kan komma från två mycket olika filer. Visa radsluten och räkna raderna innan du ändrar något. Att mäta kostar ett kommando; att gissa kostar en kväll.
cat -A /etc/openvpn/server/lab.conf | sed -n '10,20p'
awk 'NR>=10 && NR<=20 {printf "%d:%s\n", NR, $0}' /etc/openvpn/server/lab.conf
I den första utskriften visas varje verklig radbrytning som en $-markör, så en radbruten men inte delad rad visar ingen markör där skärmen bryter. Det andra kommandot skriver ut numrerade rader, vilket är det snabbaste sättet att jämföra vad parsern rapporterar med vad filen innehåller.
Extra blanksteg skapar inte heller ett direktiv. Indrag är kosmetiskt, och en rad som börjar med blanksteg är fortfarande samma enda alternativ. Om felmeddelandet pekar på ett radnummer ska du läsa just den raden i stället för stycket den tillhör.
Citera en sökväg, inte en direktivlista
Citattecken finns för argument som innehåller blanksteg, inte för att gruppera alternativ. En certifikatsökväg med ett blanksteg behöver sina egna citattecken; två direktiv som delar ett citatteckenpar är fortfarande en felaktig rad.
cert "/etc/openvpn/pki/lab certs/server.crt"
key "/etc/openvpn/pki/lab certs/server.key"
Kontrollera alternativnamnen samtidigt som layouten, eftersom en sammanfogad rad kan ge en trovärdig token som aldrig har funnits. Portdirektivet är port; en profil som använder något annat för samma idé misslyckas även efter att radgränserna har rättats. När ett namn verkar okänt ska du jämföra det med alternativlistan för den version du kör i stället för med ett forumexempel.
Håll inline-block som block
Profiler kan bära certifikat och nycklar inline, och dessa block är data snarare än konfiguration. PEM-raderna inuti ett block är inte alternativ som ska plattas ut, dras in på nytt eller sammanfogas, och blockmarkörerna måste stanna på egna rader.
Behandla ett inline-block som ett ogenomträngligt område: rätta alternativraderna runt det, lämna innehållet byte för byte ifred och klistra aldrig in det i en offentlig supporttråd. Om ett formateringsverktyg har skrivit om blocket ska du återställa det från din PKI i stället för att reparera det för hand.
Rätta det minsta avsnittet, inte mallen
Den frestande reparationen är att ersätta hela filen med en konfiguration från en handledning som ”fungerar”. Det byter ut en felaktig rad mot en uppsättning policyändringar som ingen har granskat: andra DH-parametrar, komprimeringsinställningar, chifferval, dubbla lyssnare. Det ursprungliga problemet är litet och lokalt, och ersättningen är inget av det.
Kopiera profilen till en skyddad arbetsfil, rätta radgränserna i den kopian och låt tjänstens vanliga ägare läsa in den. Starta sedan instansen och läs det första felet, om något, från början.
openvpn --config /etc/openvpn/server/lab.conf --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log
När tolkningsfasen passerar kommer nästa fel att handla om en fil, ett certifikat eller ett chiffer i stället för om ordförråd, och det är verkliga framsteg. Behåll arbetskopian och en enradsanteckning om vad som sammanfogades; samma inklistring kommer att hända igen för någon annan i samma team.