Varför det inte hjälper att lägga till opt-verify för att åtgärda OpenVPN-chifferfelet

Du hittar ett förslag att lägga till opt-verify, lägger in raden, och chifferfelet står kvar precis där det var. Det resultatet är förutsägbart, eftersom alternativet aldrig förhandlade fram ett chiffer. Det var en kontroll av alternativkonsekvens, föråldrad i 2.6 och borttagen i 2.7, och en profil som fortfarande parsas med den har inte därmed genomdrivit något.

Det hjälper att veta vad raden brukade göra innan du drar slutsatsen att den är den saknade biten. Historiken förklarar också varför den inte kan hjälpa nu.

Vad alternativet brukade genomdriva

2.6-handboken markerar opt-verify som föråldrat och beskriver det tidigare beteendet: servern släpper klienter vars angivna alternativ inte matchar dess egna, genom att jämföra saker som enhetstyp och MTU. Den kontrollen beror också på att kontrollen av alternativkonsekvens förblir aktiverad, så en server som kör med disable-occ har aldrig haft den. Lägg märke till vad jämförelsen byggs av: text som beskriver motpartens konfiguration. Den säger ingenting om vilket chiffer datakanalen kommer att använda.

Det är den första anledningen till att flaggan inte kan reparera ett chifferfel. Chiffervalet styrs av data-ciphers-policyn och av vad båda parter stöder, och en textuell konsekvenskontroll varken utökar den listan eller utför förhandlingen. Den andra anledningen är omfattningen: kontrollen handlar om huruvida angivna alternativ ser kompatibla ut, inte om kvaliteten på den väg som blir resultatet.

Vad 2.7 gör när den ser raden

I 2.7 är alternativet borta. Parsern känner fortfarande igen namnet, vilket är varför en gammal profil laddas utan syntaxfel, och den rapporterar att alternativet togs bort i stället för att gå tyst förbi det. Att känna igen ett namn och att genomdriva ett beteende är olika saker, och bara det första sker fortfarande. Borttagningsnotiserna anger skälet: när parametrar väl kan förhandlas kan två parter legitimt ha olika alternativsträngar samtidigt som de är överens om anslutningen.

En profil som parsas är därför inte bevis på att någon antagningskontroll kördes. Om din enda signal är att klienten anslöt, har du lärt dig att syntaxen accepterades.

Var felet faktiskt ligger

Behåll det första konkreta felet innan du ändrar något, eftersom senare meddelanden vanligtvis är konsekvenser av det. Ett förhandlingsfel i datakanalen hör till den godkända chifferpolicyn och till de förmågor som båda parter faktiskt annonserar. Ett fel i TLS-version eller -svit hör till kontrollkanalen. En certifikatavvisning kräver identiteten och förtroendekedjan, inte en kompatibilitetsflagga.

Identifiera också motorn i båda ändar. Ett skrivbordsprogram kan paketera en annan build än kommandoradsbinären du testade med, och alternativstödet skiljer sig mellan dem. Kontrollera den motorns dokumentation i stället för att anta att alla program som importerar en profil beter sig likadant.

Byt ut avsikten, inte bara raden

Om en äldre hanterad server verkligen förlitade sig på konsekvenskontrollen, anteckna vilken begränsning den genomdrev före uppgraderingen. Att behålla ett ignorerat alternativ i en nyare profil kan inte bevara den policyn, och att radera rader urskillningslöst kan inte heller.

Svara inte på ett gammalt förslag att alla chiffer är inaktiverade genom att aktivera varje historisk algoritm.

Efter en godkänd rättelse, granska de förhandlade resultaten på en ny anslutning och testa det program som användaren faktiskt behöver. Håll serverversionen och den effektiva policyn bredvid resultatet, så att nästa person ser vad som överenskommits i stället för vad som bara accepterats.

Målet är en stödd begränsning och en fungerande autentiserad väg, inte en ärvd flagga som fortfarande parsas.