LINUX.ORG.RU
решено ФорумAdmin

Как отключить TLS на OpenVPN-сервере?

 , ,


0

1

Требуется мне сделать маленькую домашнюю сетку между VDS-виртуалкой в интернете, на которой запущен OpenVPN сервер и роутером с прошивкой DD-WRT v3.0-r28598 std (роутер должен подключаться как клиент).


Далее я использую термины:

- Виртуалка - удаленная виртуалка с запущенным OpenVPN сервером
- linux-машина - тестовая машина с OpenVPN клиентом
- тестовое соединение - соединение между тестовой linux-машиной и виртуалкой
- роутер - роутер Tp-Link TL-WR1043ND, на котором нужно заставить работать OpenVPN клиент


Для начала я отладил конфиги сервера и клиента на тестовом соединении. Все с поддержкой TLS, по взрослому. В качестве клиента использовал тестовую linux машину с Debian. Клиент подключается, сетка создается, все хорошо. Но мне нужно подключать не linux-машину, а роутер с DD-WRT.

В интерфейсе роутера я включаю OpenVPN клиента, задаю параметры, ключи, все делаю аналогично отлаженному на linux-машине конфигу. И соединения не происходит. Ошибки такие (лог клиента):

20171106 14:44:26 I OpenVPN 2.3.8 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 24 2015
20171106 14:44:26 I library versions: OpenSSL 1.0.2e 3 Dec 2015 LZO 2.09
20171106 14:44:26 W WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
20171106 14:44:26 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20171106 14:44:26 W WARNING: file '/tmp/openvpncl/client.key' is group or others accessible
20171106 14:44:26 W WARNING: file '/tmp/openvpncl/ta.key' is group or others accessible
20171106 14:44:26 I Control Channel Authentication: using '/tmp/openvpncl/ta.key' as a OpenVPN static key file
20171106 14:44:26 I Attempting to establish TCP connection with [AF_INET]193.124.188.214:1194 [nonblock]
20171106 14:44:27 I TCP connection established with [AF_INET]193.124.188.214:1194
20171106 14:44:27 I TCPv4_CLIENT link local: [undef]
20171106 14:44:27 I TCPv4_CLIENT link remote: [AF_INET]193.124.188.214:1194
20171106 14:44:28 N VERIFY ERROR: depth=1 error=self signed certificate in certificate chain: CN=Webhamster.ru-CA
20171106 14:44:28 N TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:lib(20):func(144):reason(134)
20171106 14:44:28 N TLS Error: TLS object -> incoming plaintext read error
20171106 14:44:28 NOTE: --mute triggered...
20171106 14:44:28 1 variation(s) on previous 3 message(s) suppressed by --mute
20171106 14:44:28 N Fatal TLS error (check_tls_errors_co) restarting
20171106 14:44:28 I SIGUSR1[soft tls-error] received process restarting


По опыту отлаки конфигов на тестовом linux, я уже знаю, что такие ошибки могут быть по факту из-за одного-единственного параметра tls-cipher. Выяснилось, что даже если метод шифрования поддерживается и на клиенте, и на сервере (проверяется через команду openvpn --show-tls), то не факт, что соединение будет устанавливаться.

Так как в интерфейсе DD-WRT ограниченное число методов TLS шифрования, я только эти методы проверял на тестовом соединении. (Как мне в голову пришло это проверять? Я трое суток пытался запустить тестовое соединение с установленным методом TLS-RSA-WITH-AES-256-CBC-SHA256. Крутил все настройки кроме него. Ничего не помогало. Как только выставил TLS-RSA-WITH-AES-128-CBC-SHA, волшебным образом все заработало).

Чтобы собрать какую-то картину, я протестировал на тестовом соединении разные методы, и составил следующую таблицу:

TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 - не работает
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 - не работает
TLS-DHE-RSA-WITH-AES-128-CBC-SHA - работает!
TLS-RSA-WITH-AES-256-GCM-SHA384 - не работает
TLS-RSA-WITH-AES-256-CBC-SHA256 - не работает
TLS-RSA-WITH-AES-128-CBC-SHA - работает!
TLS-RSA-WITH-RC4-128-MD5 - работает!


Вот такая несовместимость между OpenVPN 2.3.4/OpenSSL 1.0.1t на сервере и OpenVPN 2.3.4/OpenSSL 1.0.1t на linux-клиенте (да, версии vpn и ssl абсолютно одинаковые).

Зная это, расчитывать что клиент openvpn на DD-WRT будет без проблем работать с сервером, не приходится. Так и произошло. Никакие попытки подключиться путем конфигурирования в интерфейсе не завершились успехом. Кстати на роутере имеем следующие версии: OpenVPN 2.3.8/OpenSSL 1.0.2e.

Тогда я написал для роутера скрипт, в который поместил все настройки из тестового соединения, которые гарантированно работают на linux:

https://pastebin.com/WJbqc51V

После запуска этого скрипта роутер намертво вешается, поэтому посмотреть лог клиента не могу (он в роутере не сохраняется). А на сервере видно буквально следующее:

Nov  6 15:39:49 webhamster ovpn-server[25980]: TCP connection established with [AF_INET]31.23.46.17:48391
Nov  6 15:39:50 webhamster ovpn-server[25980]: 31.23.46.17:48391 Connection reset, restarting [0]
Nov  6 15:39:53 webhamster ovpn-server[25980]: TCP connection established with [AF_INET]31.23.46.17:48392
Nov  6 15:39:56 webhamster ovpn-server[25980]: 31.23.46.17:48392 [gw0] Peer Connection Initiated with [AF_INET]31.23.46.17:48392
Nov  6 15:39:56 webhamster ovpn-server[25980]: gw0/31.23.46.17:48392 MULTI_sva: pool returned IPv4=192.168.2.51, IPv6=(Not enabled)
Nov  6 15:39:58 webhamster ovpn-server[25980]: gw0/31.23.46.17:48392 send_push_reply(): safe_cap=940
Nov  6 15:45:10 webhamster ovpn-server[25980]: gw0/31.23.46.17:48392 [gw0] Inactivity timeout (--ping-restart), restarting


Похоже, что соединение даже устанавливается. Но толку от него нету, потому что роутер висит.

* * *

В общем, после всех этих плясок я хочу попробовать установить соединение без TLS, сконфигурировав клиента просто через админку DD-WRT. Для этого в конфиге сервера убираю опции:

tls-auth /etc/openvpn/ta.key 0
tls-server
tls-cipher TLS-RSA-WITH-RC4-128-MD5


Но как только я эти опции убираю, сервер не стартует с такой ошибкой:

Nov  6 16:01:11 webhamster ovpn-server[5447]: Options error: --mode server requires --tls-server
Nov  6 16:01:11 webhamster ovpn-server[5447]: Use --help for more information.
Nov  6 16:01:11 webhamster systemd[1]: openvpn@server.service: control process exited, code=exited status=1
Nov  6 16:01:11 webhamster systemd[1]: Failed to start OpenVPN connection to server.
Nov  6 16:01:11 webhamster systemd[1]: Unit openvpn@server.service entered failed state.


Это значит, что запуск OpenVPN в режиме сервера (в конфиге присутсвует опция «mode server») невозможен без обязательного прописывания опции «tls-server»?

То есть, нынче OpenVPN невозможно запустить без TLS? Или есть какой-то метод все-таки запустить OpenVPN без поддержки TLS?

★★★★★

То есть, нынче OpenVPN невозможно запустить без TLS? Или есть какой-то метод все-таки запустить OpenVPN без поддержки TLS?

Ээээ, ну как бы OpenVPN ВСЕГДА использует TLS(режим p2p упоминаемый в man-ах я ни разу не видел). То что у тебя почему-то не срабатывает дефолт - это скорее проблема конкретной сборки. Подозреваю какие-то грабли в DD-WRT.

Например в OpenWRT некоторые пакеты собирают с/без поддержки OpenSSL(ибо размер имеет значение). Возможно и здесь что-то выпилили(что-то такое, на что show-ciphers будет мало для отладки)

Шифры с GCM поддерживаются начиная с OpenVPN 2.4 и выше, их можешь даже не пробовать.

К слову, логи на стороне сервера слишком коротки, ты точно verb поставил побольше(клиентские логи я смотрю получше)?

VERIFY ERROR: depth=1 error=self signed certificate in certificate chain: CN=Webhamster.ru-CA

Где-то CA в доверенных не прописан похоже. OpenVPN ЕМНИП плюёт на системные CA, так что хреначить надо прямо ему в конфиг. Покажи полные конфиги сервера и клиента

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Ответ на: комментарий от Pinkbyte

В общем, таки смог поднять через скрипт. Причем конфиг в скрипте не менял. Дело оказалось в конфиге сервера. Он через push неправильный маршрут командой route отправлял. Линуховая машина его проглатывала, а вот роутер переставал правильно роутить, и возникало впечатление что он завис.


VERIFY ERROR: depth=1 error=self signed certificate in certificate chain: CN=Webhamster.ru-CA

Где-то CA в доверенных не прописан похоже.

Нет, это стандартная залипуха: если что-то не так при хендшейке, и точной обработки состояния нет, OpenVPN доеб@тся к тому что сертификат самоподписан. Весь интернет забит этой ошибкой и люди начинают копать не туда, ведь дело совершенно в другом.


OpenVPN ЕМНИП плюёт на системные CA, так что хреначить надо прямо ему в конфиг.

Так и сделано. Когда OpenVPN показывает эту ошибку, получается что он плюет на CA, который вхреначен прямо ему в конфиг :)

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

А вот, например, у производителя напечатано, что при генерации сертификата авторизации надо вводить имя (полагаю доменное) или имя хоста:

howto

Common Name (eg, your name or your server's hostname) []:OpenVPN-CA

Честно признаюсь, что ни разу ещё не пробовал в CN влепить какую-нибудь пургу. Но судя по сообщениям в интернете, если, например, для домена webhamster.ru при генерации сертификата поставить Webhamster.ru-CA, то получится словно на DigitalOcean: https://www.digitalocean.com/community/questions/how-do-i-solve-a-self-signed...

howto

это стандартная залипуха: если что-то не так при хендшейке, и точной обработки состояния нет, OpenVPN доеб@тся к тому что сертификат самоподписан.

Нет такого «стандарта». Это вы выдумали. Если не генерировать сертификаты кое-как, не обращая внимания даже на howto, то «стандартные залипухи» не встречаются.

gazanit
()
Ответ на: комментарий от Pinkbyte

Точка-точка легко и непринужденно конфигурируется и работает работает. По сути от TLS он отличается тем, что в TLS клиент и сервер проверяют подлинность друг друга и потом вырабатывают совместный сеансовый ключ, а в p2p этот ключ заранее определен.

Так что если задача гарантированно точка-точка, то нечего и огород городить, статический ключ вперёд.

Nastishka ★★★★★
()
Ответ на: комментарий от gazanit

Честно признаюсь, что ни разу ещё не пробовал в CN влепить какую-нибудь пургу. Но судя по сообщениям в интернете, если, например, для домена webhamster.ru при генерации сертификата поставить Webhamster.ru-CA, то получится словно на DigitalOcean: https://www.digitalocean.com/community/questions/how-do-i-solve-a-self-signed...

Вы путаете самоподписанный корневой сертификат и сертификат клиента/сервера, который генерится на основе корневого. В самоподписанном вы можете писать любую пургу. А сертификат клиента будет сгенерирован через easyrsa v.3 вот так:

build-client-full <filename_base> [ cmd-opts ]
build-server-full <filename_base> [ cmd-opts ]
Generate a keypair and sign locally for a client or server
This mode uses the <filename_base> as the X509 CN.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Nastishka

Так что если задача гарантированно точка-точка

У меня точка-многоточка.

Xintrea ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.