At slette key-method fra en OpenVPN-profil ændrer intet

En profil, der har virket i årevis, nægter pludselig at starte, og meddelelsen nævner et direktiv, som ingen husker at have tilføjet: key-method. Det næste søgeresultat foreslår at tilføje key-method 2 for kompatibilitet, hvilket er råd fra en anden æra. Den parser, der afviste linjen, er en nutidig, og den har slet ikke en sådan indstilling. At fjerne linjen retter opstarten og ændrer intet ved, hvordan de to parter beskytter sessionen.

Det gab mellem hvad en profil indeholder, og hvad protokollen faktisk gør, er hele emnet her, og det forklarer flere andre ændringer, som folk laver samtidig. Det forklarer også, hvorfor disse ændringer har tendens til at ankomme i en samlet pakke.

Symptomet er en parsefejl, ikke en fejl i håndtrykket

Indstillinger læses, før der sendes nogen pakke. En profil med et ukendt direktiv fejler på det trin, så processen når aldrig netværket og frembringer aldrig en håndtryksfejl. Formuleringen identificerer normalt indstillingen og filen, hvilket gør dette til en af de lettere fejl at henføre. Der er ingen pakke, ingen rute og ingen firewall involveret.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Hvis meddelelsen nævner direktivet, er diagnosen færdig: filen indeholder noget, som dette build ikke accepterer. Hvis meddelelsen i stedet nævner en filsti, er problemet et manglende include eller en manglende nøgle, hvilket er en anden sektion af samme opstartstrin.

Det, du ikke bør konkludere, er at klienten eller serveren har brug for en ældre protokoltilsstand. En parsefejl er et ordforrådsproblem mellem din fil og binæren, og binæren har i dette tilfælde blot tabt et ord fra sit ordforråd.

Direktiv og wire-format er to forskellige ting

Den gamle key-method-indstilling valgte, hvordan TLS-nøgleudvekslingen blev indrammet, og den moderne udveksling er den flerpakkesmetode, som indstillingen tidligere bad om. Indstillingen forsvandt, fordi den ikke længere valgte noget; det format, den navngav, blev det eneste. At fjerne linjen efterlader derfor sessionen med samme indramning som før. En tekstændring kan ikke ændre det i nogen retning.

Derfor er det den forkerte reparation at genindføre en gammel binær for at “genskabe” metode 2. Den genskaber intet undtagen en ældre parser med ældre standardværdier, og den koster dig de rettelser, der kom efter den. Samme ræsonnement gælder for at svække et certifikattjek eller en cipher-liste i håbet om, at forbindelsen kommer tilbage.

Et nyttigt tjek er versionen og den parset konfiguration, ikke ordets tilstedeværelse i filen:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Hvad skal fjernes, og fra hvilken fil

Rediger den fil, som den kørende proces faktisk læser, og kun den fil. På pakkede systemer er det normalt profilen i den klient- eller servermappe, som uniten angiver, ikke en kopi i din hjemmemappe, som du beholder til reference. En genereret profil kan også genopbygges fra en skabelon, så en ændring, der kun er lavet i den udrullede kopi, vender tilbage efter næste provisioning-kørsel.

Slet den forældede linje, og lad endpoint, certifikater, cipher-politik og kontrolkanalindstillinger være i fred. Det er understøttede indstillinger, som processen har brug for, og de er ikke involveret i parsefejlen. Hvis samme profil indeholder andre direktiver, du ikke genkender, så tjek hvert enkelt mod den version, du kører, i stedet for at slette en gruppe af dem, indtil processen starter.

Start derefter den tilsigtede instans, og læs dens opstartsoutput. En ren start med lytteren til stede er bekræftelsen på, at dette trin er færdigt; en klienttest bagefter besvarer et andet spørgsmål.

En afvist profil og en afvist klient ligner hinanden

To fejl giver lignende supporttråde og kræver forskellige beviser. En server, der afviser sin egen konfiguration, starter aldrig, så ingen klient kan forbinde til den. En server, der starter fint og afviser én klient, kører, og dens log indeholder årsagen: et certifikatproblem, en pushet indstilling som klienten ikke accepterer, en cipher-uoverensstemmelse.

Den fjernede indstilling er ikke en diagnose for det andet tilfælde, og at gribe efter den spilder den samme time to gange. Hvis klientloggen viser serverens afvisning, så læs den afvisning; hvis den viser en lokal fejl, er klientprofilen den fil, der skal undersøges. At gribe efter et direktiv, der ikke findes mere, forsinker begge undersøgelser lige meget.

Kompatibilitetsspørgsmål, som linjen aldrig besvarede

Profiler, der cirkulerer med dette direktiv, bærer normalt en historie om en bestemt platform, og historien overlever den tekniske årsag. En mobil- eller desktopklient har stadig brug for en komplet understøttet profil: en betroet certifikatkæde, en datacipher som begge ender accepterer, en kontrolkanaltilstand som begge ender implementerer, og ingen direktiver som klientens build afviser. Intet af det afgøres af, om den gamle key-method-linje er der eller ej.

Komprimering er et separat politikspørgsmål med samme form. At fjerne en key-method-linje siger intet om, hvorvidt et komprimeringsdirektiv understøttes eller er acceptabelt i din udrulning, og de to beslutninger bør træffes uafhængigt. At slette flere sikkerhedsrelevante indstillinger på én gang, indtil noget forbinder, er måden, hvorpå en fungerende profil bliver en uforklaret.

Hold en kort registrering af, hvad du fjernede og hvorfor: indstillingen, den version der afviste den, og den kommando der viste fejlen. Den næste person, der arver profilen, får præcis brug for de tre fakta, og de er billigere at skrive ned nu end at rekonstruere senere.