OpenVPN meldt ncp-disable als onbekend: wat heeft het vervangen?

De client weigert te starten met een optiefout die ncp-disable noemt, terwijl het profiel op de vorige machine werkte. Die melding betekent niet dat de optie verkeerd gespeld is of dat de versleuteling kapot is. Ze betekent dat het binaire bestand voor u de richtlijn helemaal niet kent, en daar zijn twee heel verschillende redenen voor. Welke geldt, bepaalt of u het profiel bewerkt of de client vervangt.

De fout kan van een nieuwer binair bestand komen

Een fout over een onbekende optie gaat over de parser, niet over de tunnel. OpenVPN 2.4 voegde onderhandelbare coderingsparameters toe, 2.5 verklaarde de schakelaar die ze uitschakelde verouderd, en 2.6 verwijderde hem volledig. Daarom faalt een profiel dat voor 2.3 of 2.4 is geschreven op een huidige client, ook al is er niets in het bestand veranderd. De versie die klaagt is nieuwer, niet ouder.

Zoek uit welk uitvoerbaar bestand de melding produceerde voordat u iets bewerkt. Een desktopclient heeft zijn eigen engine, terwijl een apart geïnstalleerd binair bestand voor de opdrachtregel zijn eigen versie heeft. De twee kunnen het op dezelfde machine oneens zijn.

openvpn --version beslecht het voor het binaire bestand dat u test. Een GUI-client toont die opdracht misschien niet; lees dan het scherm Over of de versie van de meegeleverde bibliotheek.

Wat de optie werkelijk bestuurde

De richtlijn schakelde de onderhandeling over cryptografische parameters uit, zodat beide uiteinden terugvielen op ouder selectiegedrag dat door de instelling cipher werd gestuurd. Ze schakelde nooit de versleuteling uit en veranderde de tunnel nooit in platte tekst. Haar als beveiligingsschakelaar lezen is de eerste verkeerde afslag, en het leidt tot wijzigingen die de verbinding slechter maken in plaats van beter.

Zodra onderhandeling bestaat, is de gelijkwaardige vraag welke coderingen elke kant bereid is te gebruiken. Dat is een beleidsvraag, en beleid woont in data-ciphers vanaf 2.5.

De oudere naam ncp-ciphers hoort bij 2.4. De twee namen tussen kanten door elkaar halen is een veelvoorkomende bron van eenzijdige onderhandelingsfouten. Een profiel dat beide draagt, is een profiel dat door twee mensen op verschillende momenten is bewerkt.

Vervang het beleid, niet de spelling

Stel data-ciphers aan beide kanten in met een beoogde gedeelde keuze, en houd de lijst kort genoeg dat een beoordelaar erover kan nadenken. Eén willekeurige regel wijzigen bewijst niets; het resultaat hangt af van de doorsnede van beide lijsten en van wat de TLS-stack ondersteunt. Bevestig dat de kanten het eens zijn door het onderhandelde resultaat te lezen in plaats van de configuratie. Schrijf daarna beide lijsten in het uitrolverslag, zodat de volgende wijziging van een bekende toestand begint.

Werk het profiel bij via wie het bezit. Een negeeroptie toevoegen om een verouderde richtlijn te verbergen laat de beleidsvraag onbeantwoord.

Als een oudere kant echt compatibiliteitsafhandeling nodig heeft, beperk die dan tot die uitrol. Verouderd gedrag wereldwijd herstellen is geen voorwaarde om moderne kanten te verbinden. De uitzondering moet de kant noemen waarvoor ze bestaat.

Twee regels die op een coderingslijst lijken, maar het niet zijn

Twee coderingsregels stapelen herstelt de onderhandeling ook niet, en het resultaat is een profiel dat op een lijst lijkt terwijl het zich als één waarde gedraagt. Een regel met AES-256-CBC en de volgende met CBC is een veelvoorkomende poging. CBC alleen noemt een modus, geen algoritme, dus een parser kan het op de ene plaats accepteren en op de volgende afwijzen. Herhaalde cipher-richtlijnen stellen dezelfde optie twee keer in in plaats van kandidaten te verzamelen.

Controleer geaccepteerde namen met openvpn --show-ciphers op het doelbestand in plaats van een lijst te kopiëren uit een gids die voor een andere tak is geschreven. De lijst verandert tussen releases. Een naam die in de ene tak geldig is, is niet noodzakelijk geldig in de andere.

Als het doel een prestatievergelijking was, leg dan de algoritmen en de werklast vast. Overstappen op CBC is geen meting dat versleuteling ontbreekt.

Controleer wat de verbinding werkelijk heeft onderhandeld

Breng een nieuwe verbinding op en lees de datakanaalregel in het log, die de gebruikte codering noemt. De stuurkanaalsuite wordt apart bepaald, dus de toegestane lijst in het bestand toont alleen wat werd aangeboden. Wanneer de twee kanten iets hebben gekozen dat u niet verwachtte, zijn de lijsten de plek om te kijken, niet de tunnelinterface. Bevestig het resultaat op een tweede verbinding na elke wijziging, omdat één herstart een gebufferde sessie kan hergebruiken.

Bewaar het onderhandelde resultaat in het uitrolverslag naast de profielversie. Dat is het feit dat de volgende vraag beantwoordt over welke codering het verkeer werkelijk beschermt.