AES-256-GCM nie gevind nie: vermoe van die kliënt of onderhandeling?

’n OpenVPN-profiel wat elders werk, meld dat AES-256-GCM nie gevind kan word nie, of dat die ewekante geen gedeelde syfer het nie, en die eerste ingewing is om die profiel te wysig. Daardie twee boodskappe beskryf verskillende foute. Die een sê die plaaslike program het nie so ’n algoritme nie; die ander sê albei kante het algoritmes maar geen gemeenskaplike keuse nie. Om die profiel te wysig maak nie een van die twee reg nie, totdat jy weet watter een jy het.

Lees die presiese foutteks en die program wat dit opgelewer het.

Bepaal watter fout jy het

’n Boodskap oor ’n syfer wat nie gevind kan word nie, kom van opsie-ontleding op die plaaslike masjien, voordat enige pakket gestuur word. Dit beteken die uitvoerbare lêer voor jou, of die biblioteek waaraan dit koppel, bied nie daardie algoritme nie. ’n Boodskap oor geen gedeelde syfer kom later, tydens onderhandeling, en impliseer dat albei kante syfers ondersteun maar nie oor een kan ooreenkom nie.

Die onderskeid is belangrik omdat die een ’n sagteware-weergawe-probleem is en die ander ’n konfigurasie-probleem. Die eerste word deur ’n weergawenommer beslis. Die tweede word deur die vergelyking van twee lyste beslis.

’n Plaaslike vermoe-gaping

Ou gemeenskapsboue is ouer as moderne verstekwaardes, en ’n lessenaartoepassing kan sy eie enjin insluit wat verskil van ’n opdraglyn-pakket wat langsaan geïnstalleer is. Voer die kontroles uit op die uitvoerbare lêer wat die verbinding werklik begin het, en kies dan ’n ondersteunde bou eerder as om ’n ou program ’n nuwe algoritme te leer.

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

As AES-256-GCM nie in daardie lys verskyn nie, sal geen profielreël dit byvoeg nie. Die oplossing is ’n nuwer kliënt of ’n ander bou, en die beperkings van die ouer ewekant word ’n aparte ontwerpkwessie.

Vir kliënte op OpenVPN 3 verskil die enjin en die aanvaarde opdragte van die gemeenskap 2.x-lyn, dus dieselfde profielteks kan misluk om redes wat niks met die syferlys te doen het nie.

’n Onderhandelingsgaping

Wanneer albei ewekante die algoritme lys, is die oorblywende vraag watter lys elke kant bied. Gemeenskap-OpenVPN het die onderhandelingsopdrag hernoem: ncp-ciphers in 2.4 het data-ciphers in 2.5 geword, en in 2.6 dien die ouer cipher-reël meestal vir versoenbaarheid en terugval eerder as om die onderhandelde stel te bepaal.

Daarom kan die wysiging van slegs ’n ou cipher-reël die onderhandelingslys onveranderd laat. Die ou reël bly belangrik vir terugval, wat ’n aparte taak is. Om die twee te verwar lewer wysigings wat niks sigbaar verander nie.

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

Vergelyk albei eindpunte se lyste en die bediener se weieringsboodskap. As die snyding leeg is, pas die lyste doelbewus aan eerder as om ’n waarde uit ’n pos vir ’n ander weergawe te kopieer. ’n Lys wat te ruim is, verswak stilweg elke verbinding. ’n Lys wat te eng is, sluit die ewekant uit wat jy wou behou.

Hou versoenbaarheid eksplisiet

’n Terugval vir een ou ewekant is ’n besluit met ’n koste: die hele ontplooiing aanvaar ’n swakker opsie sodat een toestel kan koppel. Skryf dit as sodanig neer, en beperk dit tot die ewekant wat dit nodig het.

Twee voorwaardes bepaal die uitkoms. As die fout plaaslik is, vervang die bou. As die fout onderhandel is, pas die lyste aan beide kante aan en teken op watter weergawes jy ondersteun.

Rapporteer dan die presiese fout met die weergawe- en vermoe-uitset aangeheg. Daardie paar skei ’n ontbrekende algoritme van ’n meningsverskil, en dit stop die volgende ronde spekulatiewe wysigings voordat dit begin.