Drie verskillende feite word in die meeste OpenVPN-TLS-besprekings tot een lyn saamgevat: wat jou kliëntbou kan doen, wat die profiel toelaat en wat die sessie werklik onderhandel het. ’n Kort TLS 1.3-suitelys beantwoord net die middelste vraag halfpad, en dit sê niks oor die ondergrens van die protokolweergawe nie. Werk die kontroles hieronder in volgorde deur en stop by die eerste een wat nie standhou nie, want elke latere kontrole veronderstel dat die vroeëres afgehandel is.

Kontroleer die bou voordat jy enige lys lees

’n Konfigurasiedirektief kan nie protokolondersteuning by ’n binary voeg wat dit nie het nie. Begin met die weergawebanner, wat die ingekompileerde kriptobiblioteek noem:

openvpn --version

’n 2.6-bou wat teen OpenSSL geskakel is, aanvaar beide tls-cipher en tls-ciphersuites. ’n Bou teen mbed TLS het glad geen TLS 1.3-suitekeuse nie, en die 2.6-handleiding merk tls-ciphersuites as ’n OpenSSL-opsie. As die bediener met ’n ander backend herbou is, kan dieselfde profiel sy gedrag verander sonder dat ’n enkele reël van die konfigurasie verander.

Terwyl jy hier is, voer openvpn --show-tls uit en hou die uitset. Dit is die inventaris waarmee jy later sal vergelyk, en dit is goedkoop om dit vas te vang voordat iemand profiele begin redigeer.

Skryf die banner en die lys in die veranderingsticket, nie in ’n geselsvenster nie. Wanneer twee mense twis oor of ’n kliënt oor ses weke ’n suite kan aanbied, besleg die vasgevangde uitset dit in een lyn.

Hou weergawegrense apart van syferlyste

In die 2.6-handleiding is dit drie kontroles, nie een nie:

  • tls-cipher stel die syferbeleid vir TLS 1.2 en vroeër, wat aan OpenSSL se syferlys deurgegee word;
  • tls-ciphersuites kies TLS 1.3-suites;
  • tls-version-min en tls-version-max begrens die protokolweergawes wat die verbinding mag gebruik.

’n Noukeurig gesnoeide TLS 1.3-suitelys bewys dus niks oor ’n ouer weergawe wat steeds toegelaat word nie. As die vereiste “net TLS 1.3” is, dra die weergawe-ondergrens dit, en die suitelys vernou net die keuses binne daardie ondergrens:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Daardie paar doen twee take. As jy een van die reëls skrap, dwing die ander minder af as wat jy dink, en dit is juis die fout wat hierdie hele kontrole moet vasvang.

Die datakanale is ’n vierde kontrole. data-ciphers onderhandel die simmetriese syfer binne die tonnel, en sy resultaat sê niks oor die TLS-weergawe van die beheerkanaal nie. Om AES-256-GCM in die sessieopsomming te sien, is in geen rigting bewys vir TLS 1.3 nie.

Lees show-tls as ’n plaaslike inventaris

--show-tls lys die suites wat die kriptobiblioteek ondersteun waarteen hierdie binary geskakel is, in voorkeurorde. Dit is nie ’n verslag van die gateway nie. Die handleiding sê uitdruklik dat die lys van die plaaslike biblioteek kom, wat beteken dat ’n skootrekenaar met OpenSSL 3.x en ’n router met ’n ouer bou verskillende lyste sal druk terwyl hulle met dieselfde bediener praat.

EvidenceWhat it actually describes
--show-tls outputCapabilities of this client build and its library
Profile directivesWhat this attempt is allowed to offer
Session log lineWhat this one negotiation selected

Veronderstel ’n kliënt ondersteun suites A, B en C, en een sessie kies B. Dit bewys niks oor of die bediener A of C toelaat nie, en niks oor of B sy enigste toegelate keuse is nie. Hou die drie rye apart, en die meeste verwarrende TLS-drade los hulself op.

Die inventaris is steeds die moeite werd om te hou. Wanneer ’n sessie misluk, wys die vergelyking van die biblioteek se lys met die profiel se lys of die kliënt enige kans gehad het om aan te bied wat die bediener wou hê. Dit wys ook of ’n backend-verandering TLS_CHACHA20_POLY1305_SHA256 stilweg uit die poel verwyder het waarop ouer kliënte staatmaak — die soort regressie wat opduik as ’n handjievol gebruikers wat nie kan koppel nie, terwyl almal anders niks agterkom nie.

Vra die gateway iets wat dit kan beantwoord

As jy die diens administreer, ondersoek die effektiewe konfigurasie van die lopende instansie eerder as ’n lêer op die skyf. OpenVPN is dalk met ’n ander --config-pad begin, trek dalk insluitings in, en is dalk nie sedert die wysiging herbegin nie. Die beleid van die lopende daemon is wat kliënte teëkom.

As jy dit nie administreer nie, vra die operateur vir ondersteunde kliëntvereistes of ’n afgebakende aanvaardingstoets. ’n Verwerpte poging is nie outomaties ’n verwerpte suite nie: ’n weergawe-ondergrens, sertifikaat-identiteitskontroles soos remote-cert-tls, of ’n wanverhouding tussen tls-auth en tls-crypt kan die uitruiling beëindig voordat suitekeuse saak maak. Lees die bediener se fout voordat jy die kliënt se lys verander, want “handshake failed” dek vier verskillende oorsake en net een daarvan is ’n syferwanverhouding.

Om openssl s_client na die VPN-poort te rig, reproduseer die vraag ook nie. Die beheerkanaal loop binne OpenVPN se eie raamwerk, dus toets ’n rou TLS-peiling ’n ander protokol op ’n poort wat iets anders verwag. Enige gevolgtrekking daaruit gaan oor die peiling, nie oor die tonnel nie.

Teken twee resultate aan en hou hulle apart

’n Vars toegelate sessie lewer ’n beheerkanaal-lyn wat die protokolweergawe en die gekose syfer noem, en ’n aparte datakanaal-lyn wat die tonnelsyfer noem. Vang albei saam met die kliëntweergawe en die profielnaam vas, en noteer watter bedienerinstansie geantwoord het:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Lees dan die twee lyne uit daardie lêer eerder as uit die geheue. Die paar is die bewys; ’n suitenaam alleen is ’n voorkeur, en die weergawegrens is ’n aparte stelling oor wat die bediener weier.

Voer die kontroles in hierdie volgorde uit. Bevestig die bou en backend met --version. Vang --show-tls vas voordat jy enigiets verander. Noem die vereiste weergawe-ondergrens apart van die suitelys. Bevestig die lopende instansie se effektiewe beleid by die eienaar daarvan. Neem een toegelate sessie waar en, as die plan dit toelaat, een verwerpte poging met ’n ouer weergawe. Teken die beheerkanaal- en datakanaalresultate as aparte bevindings aan.

As ’n vereiste kliënt nie ’n nuwe minimum kan haal nie, maak daardie migrasie- of uitsonderingbesluit uitdruklik eerder as om stilweg ’n onverwante aanvaardingsreël te verlaag sodat die uitrol klaar lyk.

Verwante artikels