Три различни факта се смачкват в един ред в повечето дискусии за OpenVPN и TLS: какво може вашата клиентска компилация, какво позволява профилът и какво всъщност е договорила сесията. Краткият списък с набори за TLS 1.3 отговаря само наполовина на средния въпрос и не казва нищо за долната граница на версията на протокола. Минавайте през проверките по-долу по ред и спрете на първата, която не издържи, защото всяка следваща проверка предполага, че предишните са решени.

Проверете компилацията, преди да четете какъвто и да е списък

Директива в конфигурацията не може да добави поддръжка на протокол към двоичен файл, който я няма. Започнете с банера за версията, който посочва компилираната криптографска библиотека:

openvpn --version

Компилация 2.6, свързана с OpenSSL, приема както tls-cipher, така и tls-ciphersuites. Компилация с mbed TLS няма никакъв избор на набори за TLS 1.3, а ръководството за 2.6 отбелязва tls-ciphersuites като опция на OpenSSL. Ако сървърът бъде прекомпилиран с друг backend, същият профил може да промени поведението си, без да се промени нито един ред от конфигурацията.

Докато сте тук, изпълнете openvpn --show-tls и запазете изхода. Това е инвентарът, с който ще сравнявате по-късно, и е евтино да го уловите, преди някой да започне да редактира профили.

Запишете банера и списъка в билета за промяната, а не в чат прозорец. Когато двама души спорят дали клиент може да предложи набор след шест седмици, уловеният изход решава въпроса в един ред.

Дръжте границите на версията отделно от списъците с шифри

В ръководството за 2.6 това са три контрола, а не един:

  • tls-cipher задава политиката за шифри за TLS 1.2 и по-стари и се предава на списъка с шифри на OpenSSL;
  • tls-ciphersuites избира набори за TLS 1.3;
  • tls-version-min и tls-version-max ограничават версиите на протокола, които връзката може да използва.

Затова внимателно подрязаният списък с набори за TLS 1.3 не доказва нищо за това, че по-стара версия все още е разрешена. Ако изискването е „само TLS 1.3“, долната граница на версията го носи, а списъкът с набори само стеснява избора в тази граница:

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

Тази двойка върши две работи. Изтриването на един от редовете оставя другия да налага по-малко, отколкото мислите, и това е точно провалът, за чието улавяне съществува цялата тази проверка.

Каналът за данни е четвърти контрол. data-ciphers договаря симетричната шифра вътре в тунела и резултатът му не казва нищо за версията на TLS на контролния канал. Виждането на AES-256-GCM в обобщението на сесията не е доказателство за TLS 1.3 в нито една посока.

Четете show-tls като локален инвентар

--show-tls изброява наборите, поддържани от криптографската библиотека, с която е свързан този двоичен файл, в ред на предпочитание. Това не е отчет от шлюза. Ръководството изрично казва, че списъкът идва от локалната библиотека, което означава, че лаптоп с OpenSSL 3.x и рутер с по-стара компилация ще отпечатат различни списъци, докато говорят със същия сървър.

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

Да предположим, че клиент поддържа набори A, B и C и една сесия избира B. Това не установява нищо за това дали сървърът разрешава A или C, нито дали B е единственият му разрешен избор. Дръжте трите реда отделно и повечето объркващи теми за TLS ще се решат сами.

Инвентарът все пак си струва да се пази. Когато сесия се провали, сравняването на списъка на библиотеката със списъка на профила показва дали клиентът е имал някакъв шанс да предложи това, което сървърът е искал. Показва и дали промяна в backend тихо е премахнала TLS_CHACHA20_POLY1305_SHA256 от пула, на който разчитат по-стари клиенти — видът регресия, който се проявява като шепа потребители, които не могат да се свържат, докато всички останали не забелязват нищо.

Попитайте шлюза нещо, на което може да отговори

Ако администрирате услугата, прегледайте ефективната конфигурация на работещата инстанция, а не файл на диска. OpenVPN може да е стартиран с друг път --config, може да изтегля включвания и може да не е рестартиран след редакцията. Политиката на работещия демон е това, което срещат клиентите.

Ако не я администрирате, попитайте оператора за поддържани изисквания към клиентите или за ограничен приемателен тест. Отхвърленият опит не е автоматично отхвърлен набор: долна граница на версията, проверки за идентичност на сертификата като remote-cert-tls или несъответствие между tls-auth и tls-crypt могат да прекратят размяната, преди изборът на набор да има значение. Прочетете грешката на сървъра, преди да промените списъка на клиента, защото „handshake failed“ покрива четири различни причини и само една от тях е несъответствие на шифъра.

Насочването на openssl s_client към VPN порта също не възпроизвежда въпроса. Контролният канал работи вътре в собственото рамкиране на OpenVPN, така че суровата TLS проба тества различен протокол на порт, който очаква нещо друго. Всяко заключение от нея е за пробата, не за тунела.

Запишете два резултата и ги дръжте отделно

Нова разрешена сесия създава ред за контролния канал с версията на протокола и избраната шифра и отделен ред за канала за данни с шифрата на тунела. Уловете и двата с версията на клиента и името на профила и отбележете коя инстанция на сървъра е отговорила:

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

След това прочетете двата реда от този файл, а не от паметта. Двойката е доказателството; едно име на набор е предпочитание, а границата на версията е отделно твърдение за това какво отказва сървърът.

Изпълнете проверките в този ред. Потвърдете компилацията и backend с --version. Уловете --show-tls преди да промените каквото и да е. Посочете изискваната долна граница на версията отделно от списъка с набори. Потвърдете ефективната политика на работещата инстанция с нейния собственик. Наблюдавайте една разрешена сесия и, ако планът позволява, един отхвърлен опит със стара версия. Запишете резултатите за контролния канал и канала за данни като отделни констатации.

Ако задължителен клиент не може да покрие нов минимум, вземете решението за миграция или изключение изрично, вместо тихо да намалите несвързано правило за приемане, за да изглежда внедряването завършено.

Подобни статии