OpenVPN siger, at ncp-disable er ukendt: hvad erstattede det?

Klienten nægter at starte med en indstillingsfejl, der nævner ncp-disable, og profilen virkede på den forrige maskine. Beskeden betyder ikke, at indstillingen er stavet forkert, eller at krypteringen er i stykker. Den betyder, at den binære fil foran dig slet ikke kender direktivet, og der er to meget forskellige grunde til det. Hvilken der gælder, afgør, om du redigerer profilen eller skifter klienten.

Fejlen kan komme fra en nyere binær fil

En fejl om ukendt indstilling handler om parseren, ikke tunnelen. OpenVPN 2.4 tilføjede forhandlingsbare krypteringsparametre, 2.5 erklærede kontakten, der slog dem fra, forældet, og 2.6 fjernede den helt. Derfor fejler en profil skrevet til 2.3 eller 2.4 på en nuværende klient, selv om intet i filen er ændret. Den version, der klager, er nyere, ikke ældre.

Find ud af, hvilken eksekverbar fil der gav beskeden, før du redigerer noget. En skrivebordsklient har sin egen motor, mens en separat installeret binær fil til kommandolinjen har sin egen version. De to kan være uenige på samme maskine.

Med openvpn --version afgøres det for den binære fil, du tester. En GUI-klient viser måske ikke kommandoen, og så skal du læse dens om-skærm eller versionen af det medfølgende bibliotek.

Hvad indstillingen egentlig styrede

Direktivet slog forhandlingen af kryptografiske parametre fra, så begge ender faldt tilbage til ældre valgadfærd styret af indstillingen cipher. Det slog aldrig kryptering fra og gjorde aldrig tunnelen til klartekst. At læse det som en sikkerhedskontakt er det første forkerte sving, og det fører til ændringer, der gør forbindelsen dårligere i stedet for bedre.

Når forhandling findes, er det tilsvarende spørgsmål, hvilke krypteringsalgoritmer hver side er villig til at bruge. Det er et politisk spørgsmål, og politik ligger i data-ciphers på 2.5 og senere.

Det ældre navn ncp-ciphers hører til 2.4. At blande de to navne mellem parter er en hyppig kilde til ensidige forhandlingsfejl. En profil, der bærer begge, er en profil redigeret af to personer på forskellige tidspunkter.

Erstat politikken, ikke stavemåden

Sæt data-ciphers på begge parter med et tilsigtet fælles valg, og hold listen kort nok til, at en anmelder kan tænke over den. At ændre én vilkårlig linje beviser intet; resultatet afhænger af fællesmængden af begge lister og af, hvad TLS-stakken understøtter. Bekræft, at parterne er enige, ved at læse det forhandlede resultat i stedet for konfigurationen. Skriv derefter de to lister ind i udrulningsoptegnelsen, så den næste ændring starter fra en kendt tilstand.

Opdater profilen gennem den, der ejer den. At tilføje en ignorer-indstilling for at skjule et forældet direktiv efterlader politikspørgsmålet ubesvaret.

Hvis en ældre part virkelig har brug for kompatibilitetsbehandling, så begræns den til den udrulning. At gendanne forældet adfærd globalt er ikke en forudsætning for at forbinde moderne parter. Undtagelsen bør navngive den part, den findes for.

To linjer, der ligner en krypteringsliste, men ikke er det

At stable to krypteringslinjer gendanner heller ikke forhandlingen, og resultatet er en profil, der ser ud som en liste, men opfører sig som en enkelt værdi. En linje med AES-256-CBC og den næste med CBC er et almindeligt forsøg. CBC alene navngiver en tilstand, ikke en algoritme, så en parser kan acceptere den på én plads og afvise den på den næste. Gentagne cipher-direktiver sætter den samme indstilling to gange i stedet for at samle kandidater.

Kontrollér accepterede navne med openvpn --show-ciphers på den binære fil, du målretter, i stedet for at kopiere en liste fra en guide skrevet til en anden gren. Listen ændrer sig mellem udgivelser. Et navn, der er gyldigt i én gren, er ikke nødvendigvis gyldigt i den anden.

Hvis målet var en ydeevnesammenligning, så notér algoritmerne og belastningen. At skifte til CBC er ikke en måling af, at kryptering mangler.

Kontrollér, hvad forbindelsen faktisk forhandlede

Opret en ny forbindelse, og læs data-kanal-linjen i loggen, som angiver den anvendte kryptering. Kontrolkanalens suite besluttes separat, så den tilladte liste i filen viser kun, hvad der blev tilbudt. Når de to parter har valgt noget, du ikke forventede, er listerne stedet at kigge, ikke tunnelinterfacet. Bekræft resultatet på en anden forbindelse efter enhver ændring, fordi en genstart kan genbruge en cachet session.

Opbevar det forhandlede resultat i udrulningsoptegnelsen ved siden af profilversionen. Det er det faktum, der besvarer det næste spørgsmål om, hvilken kryptering der reelt beskytter trafikken.