OpenVPN säger att ncp-disable är okänt: vad ersatte det?

Klienten vägrar starta med ett alternativfel som nämner ncp-disable, trots att profilen fungerade på den förra maskinen. Meddelandet betyder inte att alternativet är felstavat eller att krypteringen är trasig. Det betyder att binärfilen framför dig inte känner till direktivet alls, och det finns två mycket olika skäl till det. Vilket som gäller avgör om du redigerar profilen eller byter klient.

Felet kan komma från en nyare binärfil

Ett fel om okänt alternativ handlar om tolken, inte om tunneln. OpenVPN 2.4 lade till förhandlingsbara krypteringsparametrar, 2.5 förklarade strömbrytaren som stängde av dem föråldrad, och 2.6 tog bort den helt. Därför misslyckas en profil skriven för 2.3 eller 2.4 på en nuvarande klient, även om ingenting i filen har ändrats. Versionen som klagar är nyare, inte äldre.

Ta reda på vilken körbar fil som gav meddelandet innan du redigerar något. En skrivbordsklient har sin egen motor, medan en separat installerad binärfil för kommandoraden har sin egen version. De två kan vara oense på samma maskin.

openvpn --version avgör det för binärfilen du testar. En GUI-klient visar kanske inte kommandot, och då bör du läsa dess Om-skärm eller versionen av det medföljande biblioteket.

Vad alternativet egentligen styrde

Direktivet stängde av förhandlingen av kryptografiska parametrar, så båda ändarna föll tillbaka på äldre urvalsbeteende som styrdes av inställningen cipher. Det stängde aldrig av krypteringen och gjorde aldrig tunneln till klartext. Att läsa det som en säkerhetsbrytare är det första felaktiga draget, och det leder till ändringar som gör anslutningen sämre i stället för bättre.

När förhandling finns är den motsvarande frågan vilka krypteringar varje sida är beredd att använda. Det är en policyfråga, och policyn bor i data-ciphers från 2.5 och framåt.

Det äldre namnet ncp-ciphers hör till 2.4. Att blanda de två namnen mellan parterna är en vanlig källa till ensidiga förhandlingsfel. En profil som bär båda är en profil som redigerats av två personer vid olika tillfällen.

Byt ut policyn, inte stavningen

Sätt data-ciphers på båda parter med ett avsett gemensamt val, och håll listan kort nog för att en granskare ska kunna resonera om den. Att ändra en godtycklig rad bevisar ingenting; resultatet beror på snittet mellan båda listorna och på vad TLS-stacken stöder. Bekräfta att parterna är överens genom att läsa det förhandlade resultatet i stället för konfigurationen. Skriv sedan in båda listorna i utrullningsjournalen så att nästa ändring börjar från ett känt läge.

Uppdatera profilen genom den som äger den. Att lägga till ett ignoreringsalternativ för att dölja ett föråldrat direktiv lämnar policyfrågan obesvarad.

Om en äldre part verkligen behöver kompatibilitetshantering, begränsa den till den utrullningen. Att återställa föråldrat beteende globalt är inget förkrav för att ansluta moderna parter. Undantaget bör namnge den part det finns för.

Två rader som ser ut som en krypteringslista men inte är det

Att stapla två krypteringsrader återställer inte heller förhandlingen, och resultatet är en profil som ser ut som en lista men beter sig som ett enda värde. En rad med AES-256-CBC och nästa med CBC är ett vanligt försök. CBC ensamt namnger ett läge, inte en algoritm, så en tolk kan acceptera det på ett ställe och avvisa det på nästa. Upprepade cipher-direktiv sätter samma alternativ två gånger i stället för att samla kandidater.

Kontrollera accepterade namn med openvpn --show-ciphers på målbinärfilen i stället för att kopiera en lista från en guide skriven för en annan gren. Listan ändras mellan utgåvor. Ett namn som är giltigt i en gren är inte nödvändigtvis giltigt i den andra.

Om målet var en prestandajämförelse, notera algoritmerna och arbetsbelastningen. Att byta till CBC är inte en mätning av att kryptering saknas.

Kontrollera vad anslutningen faktiskt förhandlade

Öppna en ny anslutning och läs datakanalraden i loggen, som namnger krypteringen som används. Kontrollkanalssviten avgörs separat, så den tillåtna listan i filen visar bara vad som erbjöds. När de två parterna har valt något du inte förväntade dig är listorna stället att titta på, inte tunnelgränssnittet. Bekräfta resultatet på en andra anslutning efter varje ändring, eftersom en omstart kan återanvända en cachad session.

Förvara det förhandlade resultatet i utrullningsjournalen bredvid profilversionen. Det är det faktum som besvarar nästa fråga om vilken kryptering som verkligen skyddar trafiken.