OpenVPN sier at ncp-disable er ukjent: hva erstattet det?

Klienten nekter å starte med en valgfeil som nevner ncp-disable, mens profilen virket på den forrige maskinen. Denne meldingen betyr ikke at valget er stavet feil eller at krypteringen er ødelagt. Den betyr at binærfilen foran deg ikke kjenner direktivet i det hele tatt, og det er to svært forskjellige grunner til det. Hvilken som gjelder avgjør om du redigerer profilen eller bytter klient.

Feilen kan komme fra en nyere binærfil

En feil om ukjent valg handler om parseren, ikke tunnelen. OpenVPN 2.4 la til forhandlingsbare krypteringsparametere, 2.5 erklærte bryteren som slo dem av som utdatert, og 2.6 fjernet den helt. Derfor feiler en profil skrevet for 2.3 eller 2.4 på en nåværende klient, selv om ingenting i filen er endret. Versjonen som klager er nyere, ikke eldre.

Finn ut hvilken kjørbar fil som ga meldingen før du redigerer noe. En skrivebordsklient har sin egen motor, mens en separat installert binærfil for kommandolinjen har sin egen versjon. De to kan være uenige på samme maskin.

openvpn --version avgjør det for binærfilen du tester. En GUI-klient viser kanskje ikke kommandoen, og da bør du lese om-skjermen eller versjonen til biblioteket som følger med.

Hva valget faktisk styrte

Direktivet slo av forhandlingen av kryptografiske parametere, slik at begge ender falt tilbake til eldre valgatferd styrt av innstillingen cipher. Det slo aldri av kryptering og gjorde aldri tunnelen om til klartekst. Å lese det som en sikkerhetsbryter er den første feilsvingen, og det fører til endringer som gjør forbindelsen dårligere i stedet for bedre.

Når forhandling finnes, er det tilsvarende spørsmålet hvilke krypteringer hver side er villig til å bruke. Det er et policy-spørsmål, og policyen bor i data-ciphers fra 2.5 og senere.

Det eldre navnet ncp-ciphers hører til 2.4. Å blande de to navnene mellom parter er en vanlig kilde til ensidige forhandlingsfeil. En profil som bærer begge, er en profil redigert av to personer på forskjellige tidspunkter.

Erstatt policyen, ikke stavemåten

Sett data-ciphers på begge parter med et tilsiktet felles valg, og hold listen kort nok til at en anmelder kan tenke over den. Å endre én vilkårlig linje beviser ingenting; resultatet avhenger av snittet mellom begge listene og av hva TLS-stakken støtter. Bekreft at partene er enige ved å lese det forhandlede resultatet i stedet for konfigurasjonen. Skriv deretter begge listene inn i utrullingsprotokollen, slik at neste endring starter fra en kjent tilstand.

Oppdater profilen gjennom den som eier den. Å legge til et ignoreringsvalg for å skjule et utdatert direktiv lar policy-spørsmålet stå ubesvart.

Hvis en eldre part virkelig trenger kompatibilitetsbehandling, begrens den til den utrullingen. Å gjenopprette utdatert atferd globalt er ikke en forutsetning for å koble sammen moderne parter. Unntaket bør navngi parten det finnes for.

To linjer som ser ut som en krypteringsliste, men ikke er det

Å stable to krypteringslinjer gjenoppretter heller ikke forhandlingen, og resultatet er en profil som ser ut som en liste mens den oppfører seg som én verdi. En linje med AES-256-CBC og den neste med CBC er et vanlig forsøk. CBC alene navngir en modus, ikke en algoritme, så en parser kan godta det på ett sted og avvise det på det neste. Gjentatte cipher-direktiver setter samme valg to ganger i stedet for å samle kandidater.

Kontroller aksepterte navn med openvpn --show-ciphers på målbinærfilen i stedet for å kopiere en liste fra en veiledning skrevet for en annen gren. Listen endrer seg mellom utgivelser. Et navn som er gyldig i én gren, er ikke nødvendigvis gyldig i den andre.

Hvis målet var en ytelsessammenligning, noter algoritmene og arbeidsbelastningen. Å bytte til CBC er ikke en måling av at kryptering mangler.

Kontroller hva forbindelsen faktisk forhandlet

Sett opp en ny forbindelse og les datakanallinjen i loggen, som navngir krypteringen som brukes. Kontrollkanalsuiten avgjøres separat, så den tillatte listen i filen viser bare hva som ble tilbudt. Når de to partene har valgt noe du ikke forventet, er listene stedet å se, ikke tunnelgrensesnittet. Bekreft resultatet på en andre forbindelse etter enhver endring, fordi en omstart kan gjenbruke en bufret økt.

Oppbevar det forhandlede resultatet i utrullingsprotokollen ved siden av profilversjonen. Det er faktumet som svarer på det neste spørsmålet om hvilken kryptering som faktisk beskytter trafikken.