AES-256-GCM hittades inte: klientens förmåga eller förhandlingen?

En OpenVPN-profil som fungerar någon annanstans rapporterar att AES-256-GCM inte hittas, eller att parterna inte delar något chiffer, och den första impulsen är att redigera profilen. De två meddelandena beskriver olika fel. Det ena säger att det lokala programmet inte har den algoritmen; det andra att båda sidor har algoritmer men ingen gemensam valmöjlighet. Att redigera profilen löser inget av dem förrän du vet vilket du har.

Läs den exakta feltexten och programmet som producerade den.

Avgör vilket fel du har

Meddelandet om ett chiffer som inte hittas kommer från valtolkningen på den lokala maskinen, innan något paket skickas. Det betyder att den körbara filen framför dig, eller biblioteket den länkar mot, inte erbjuder den algoritmen. Meddelandet om inget gemensamt chiffer kommer senare, under förhandlingen, och betyder att båda sidor stöder chiffer men inte kan enas om ett.

Skillnaden spelar roll eftersom det ena är ett problem med mjukvaruversionen och det andra ett konfigurationsproblem. Det första avgörs av ett versionsnummer. Det andra avgörs genom att jämföra två listor.

En lokal förmågebrist

Gamla community-byggen är äldre än de moderna standardvärdena, och ett skrivbordsprogram kan ta med sin egen motor som skiljer sig från kommandoradespaketet som installerats bredvid. Kör kontrollerna på den körbara fil som faktiskt startade anslutningen och välj sedan ett bygge som stöds i stället för att lära ett gammalt program en ny algoritm.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Om AES-256-GCM inte finns i den listan lägger ingen profilrad till det. Lösningen är en nyare klient eller ett annat bygge, och den äldre sidans begränsningar blir en egen designfråga.

För klienter baserade på OpenVPN 3 skiljer sig motorn och de accepterade direktiven från community-linjen 2.x, så samma profiltext kan misslyckas av skäl som inte har något med chifferlistan att göra.

En brist i förhandlingen

När båda parterna listar algoritmen återstår frågan vilken lista varje sida erbjuder. Community-OpenVPN bytte namn på förhandlingsdirektivet: ncp-ciphers i 2.4 blev data-ciphers i 2.5, och i 2.6 tjänar den äldre cipher-raden mest kompatibilitet och återfall snarare än att definiera den förhandlade uppsättningen.

Därför kan en ändring av bara en gammal cipher-rad lämna förhandlingslistan orörd. Den gamla raden är fortfarande viktig för återfall, och det är en separat uppgift. Att blanda de två ger ändringar som inte ändrar något synligt.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Jämför listorna i båda ändarna och serverns avvisningsmeddelande. Om snittet är tomt, justera listorna medvetet i stället för att kopiera ett värde från ett inlägg skrivet för en annan version. En för vid lista försvagar tyst varje anslutning. En för snäv lista utesluter den part du ville behålla.

Håll kompatibiliteten explicit

Ett återfall för en gammal part är ett beslut med en kostnad: hela utrullningen accepterar ett svagare alternativ så att en enhet kan ansluta. Skriv ned det som sådant och begränsa det till den part som behöver det.

Två villkor avgör utfallet. Om felet är lokalt, byt ut bygget. Om felet är förhandlat, justera listorna i båda ändarna och notera vilka versioner du stöder.

Rapportera sedan det exakta felet med versions- och förmågeutdata bifogat. Det paret skiljer en saknad algoritm från en oenighet och stoppar nästa omgång spekulativa ändringar innan den börjar.