AES-256-GCM blev ikke fundet: klientens evne eller forhandling?

En OpenVPN-profil, der virker andre steder, melder, at AES-256-GCM ikke kan findes, eller at parterne ikke deler nogen cipher, og den første indskydelse er at redigere profilen. De to meddelelser beskriver forskellige fejl. Den ene siger, at det lokale program ikke har den algoritme; den anden, at begge ender har algoritmer, men ikke et fælles valg. At redigere profilen løser ingen af dem, før du ved, hvilken du har.

Læs den præcise fejltekst og det program, der producerede den.

Afgør, hvilken fejl du har

Meddelelsen om en cipher, der ikke kan findes, kommer fra valgmulighedsfortolkning på den lokale maskine, før der sendes nogen pakke. Det betyder, at den eksekverbare fil foran dig, eller det bibliotek den linker til, ikke tilbyder den algoritme. Meddelelsen om ingen fælles cipher kommer senere under forhandlingen og betyder, at begge sider understøtter ciphers, men ikke kan blive enige om én.

Forskellen betyder noget, fordi den ene er et problem med softwareversionen og den anden et konfigurationsproblem. Den første afgøres af et versionsnummer. Den anden afgøres ved at sammenligne to lister.

Et lokalt hul i evnerne

Gamle fællesskabsbuilds er ældre end de moderne standarder, og et skrivebordsprogram kan medbringe sin egen motor, som afviger fra den kommandolinjepakke, der er installeret ved siden af. Kør kontrollerne på den eksekverbare fil, der faktisk startede forbindelsen, og vælg derefter et understøttet build i stedet for at lære et gammelt program en ny algoritme.

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

Hvis AES-256-GCM ikke optræder i den liste, tilføjer ingen profillinje den. Løsningen er en nyere klient eller et andet build, og den ældre parts begrænsninger bliver et separat designspørgsmål.

For klienter baseret på OpenVPN 3 afviger motoren og de accepterede direktiver fra fællesskabslinjen 2.x, så den samme profiltekst kan fejle af grunde, der intet har med cipher-listen at gøre.

Et hul i forhandlingen

Når begge parter lister algoritmen, er spørgsmålet, hvilken liste hver side tilbyder. Fællesskabs-OpenVPN omdøbte forhandlingsdirektivet: ncp-ciphers i 2.4 blev data-ciphers i 2.5, og i 2.6 tjener den ældre cipher-linje mest kompatibilitet og fallback frem for at definere det forhandlede sæt.

Derfor kan en ændring af kun en gammel cipher-linje lade forhandlingslisten urørt. Den gamle linje er stadig vigtig for fallback, og det er en separat opgave. At blande de to giver ændringer, der ikke ændrer noget synligt.

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

Sammenlign begge enders lister og serverens afvisning. Hvis snittet er tomt, skal du justere listerne bevidst i stedet for at kopiere en værdi fra et indlæg skrevet til en anden version. En for bred liste svækker stille hver forbindelse. En for snæver liste udelukker den part, du ville beholde.

Hold kompatibilitet eksplicit

En fallback for en gammel part er en beslutning med en pris: hele udrulningen accepterer en svagere mulighed, for at én enhed kan forbinde. Skriv det som sådan, og begræns det til den part, der har brug for det.

To betingelser afgør udfaldet. Er fejlen lokal, udskift buildet. Er fejlen forhandlet, juster listerne i begge ender, og noter hvilke versioner du understøtter.

Rapportér derefter den præcise fejl med versions- og evneoutput vedhæftet. Det par skiller en manglende algoritme fra en uenighed og stopper næste runde af spekulative ændringer, før den begynder.