Å slette key-method fra en OpenVPN-profil endrer ingenting

En profil som har fungert i årevis nekter plutselig å starte, og meldingen navngir et direktiv som ingen husker å ha lagt til: key-method. Det neste søkeresultatet foreslår å legge til key-method 2 for kompatibilitet, noe som er råd fra en annen tid. Parseren som avviste linjen er en nåværende, og den har ikke et slikt alternativ i det hele tatt. Å fjerne linjen retter oppstarten, og det endrer ingenting ved hvordan de to partene beskytter sesjonen.

Nettopp dette gapet mellom hva en profil inneholder og hva protokollen faktisk gjør er hele temaet her, og det forklarer flere andre endringer folk gjør samtidig. Det forklarer også hvorfor disse endringene vanligvis kommer i én samlet pakke.

Symptomet er en parsefeil, ikke en feil i håndtrykket

Alternativer leses før noen pakke sendes. En profil med et ukjent direktiv feiler i den fasen, så prosessen når aldri nettverket og produserer aldri en håndtrykksfeil. Formuleringen navngir vanligvis alternativet og filen, noe som gjør dette til en av de enkleste feilene å tilskrive. Ingen pakke, rute eller brannmur er involvert.

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

Hvis meldingen navngir direktivet, er diagnosen ferdig: filen inneholder noe denne byggingen ikke godtar. Hvis meldingen i stedet navngir en filsti, er problemet en manglende include eller nøkkel, som er en annen del av samme oppstartsfase.

Det du ikke bør konkludere, er at klienten eller serveren trenger en eldre protokollmodus. En parsefeil er et ordforrådsproblem mellom filen din og binærfilen, og binærfilen har i dette tilfellet rett og slett sluppet et ord fra ordforrådet sitt.

Direktiv og overføringsformat er to forskjellige ting

Det gamle key-method-alternativet valgte hvordan TLS-nøkkelutvekslingen ble innrammet, og den moderne utvekslingen er metoden med flere pakker som alternativet en gang ba om. Alternativet forsvant fordi det ikke lenger valgte noe; formatet det navnga ble det eneste. Å fjerne linjen lar derfor sesjonen bruke samme innramming som før. En tekstendring kan ikke endre det i noen retning.

Derfor er det feil reparasjon å gjeninnføre en gammel binærfil for å «gjenopprette» metode 2. Det gjenoppretter ingenting unntatt en eldre parser med eldre standardverdier, og det koster deg rettelsene som kom etter den. Samme resonnement gjelder for å svekke en sertifikatkontroll eller en sifferliste i håp om at tilkoblingen kommer tilbake.

En nyttig kontroll er versjonen og den parsede konfigurasjonen, ikke om ordet finnes i filen:

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

Hva som skal fjernes, og fra hvilken fil

Rediger filen den kjørende prosessen faktisk leser, og bare den filen. På pakkede systemer er det vanligvis profilen i klient- eller serverkatalogen som enheten navngir, ikke en kopi i hjemmekatalogen din som du beholder som referanse. En generert profil kan også bygges på nytt fra en mal, så en endring som bare er gjort i den utrullede kopien kommer tilbake etter neste provisioning-kjøring.

Slett den utdaterte linjen og la endepunktet, sertifikatene, sifferpolicyen og innstillingene for kontrollkanalen være i fred. Dette er støttede alternativer som prosessen trenger, og de er ikke involvert i parsefeilen. Hvis samme profil inneholder andre direktiver du ikke kjenner igjen, sjekk hvert enkelt mot versjonen du kjører i stedet for å slette en gruppe av dem til prosessen starter.

Start deretter den tiltenkte instansen og les oppstartsutdataene. En ren start med lytteren til stede er bekreftelsen på at denne fasen er ferdig; en klienttest etterpå svarer på et annet spørsmål.

En avvist profil og en avvist klient ser like ut

To feil gir lignende støttetråder og krever ulike bevis. En server som avviser sin egen konfigurasjon starter aldri, så ingen klient kan koble til den. En server som starter fint og avviser én klient kjører, og loggen inneholder årsaken: et sertifikatproblem, et dyttet alternativ klienten ikke godtar, et sifferavvik.

Det fjernede alternativet er ikke en diagnose for det andre tilfellet, og å gripe etter det sløser bort den samme timen to ganger. Hvis klientloggen viser serverens avvisning, les den avvisningen; hvis den viser en lokal feil, er klientprofilen filen som skal undersøkes. Å gripe etter et direktiv som ikke finnes lenger, forsinker begge undersøkelsene like mye.

Kompatibilitetsspørsmål linjen aldri besvarte

Profiler som sirkulerer med dette direktivet bærer vanligvis en historie om en bestemt plattform, og historien overlever den tekniske årsaken. En mobil- eller stasjonærklient trenger fortsatt en komplett støttet profil: en klarert sertifikatkjede, et datasiffer begge ender godtar, en kontrollkanalmodus begge ender implementerer, og ingen direktiver klientens bygging avviser. Ingenting av dette avgjøres av om den gamle key-method-linjen er der eller ikke.

Komprimering er et eget policyspørsmål med samme form. Å fjerne en key-method-linje sier ingenting om hvorvidt et komprimeringsdirektiv støttes eller er akseptabelt i utrullingen din, og de to beslutningene bør tas uavhengig av hverandre. Å slette flere sikkerhetsrelevante innstillinger på en gang til noe kobler til, er måten en fungerende profil blir en uforklart profil.

Hold en kort oversikt over hva du fjernet og hvorfor: alternativet, versjonen som avviste det, og kommandoen som viste feilen. Den neste personen som arver profilen vil trenge nøyaktig de tre faktumene, og de er billigere å skrive ned nå enn å rekonstruere senere.