Проблемы с OpenVPN

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-02 14:10:17

Приветствую.
Объединил два офиса посредством OpenVPN. Информацию по настройке в основном брал на этом ресурсе.
Вроде, всё заработало, но периодически случаются проблемы. Выглядит это так:
Соединение между клиентом и сервером как бы есть (по крайней мере OpenVPN-Control) показывает его наличие), но пакеты между сетями ходить перестают. Ни сервер, ни какие другие ресурсы со стороны клиента не пингуются. Если в этот момент посмотреть лог на клиенте, то там видно следующее:

Код: Выделить всё

Tue Jul  2 13:26:32 2013 [UNDEF] Inactivity timeout (--ping-restart), restarting
Tue Jul  2 13:26:32 2013 TCP/UDP: Closing socket
Tue Jul  2 13:26:32 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Jul  2 13:26:32 2013 Restart pause, 2 second(s)
Tue Jul  2 13:26:34 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul  2 13:26:34 2013 Re-using SSL/TLS context
Tue Jul  2 13:26:34 2013 LZO compression initialized
Tue Jul  2 13:26:34 2013 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Jul  2 13:26:34 2013 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Jul  2 13:26:34 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jul  2 13:26:34 2013 Local Options hash (VER=V4): '504e774e'
Tue Jul  2 13:26:34 2013 Expected Remote Options hash (VER=V4): '14168603'
Tue Jul  2 13:26:34 2013 UDPv4 link local (bound): [undef]
Tue Jul  2 13:26:34 2013 UDPv4 link remote: [AF_INET]123.123.123.123:1194
Tue Jul  2 13:26:34 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul  2 13:26:34 2013 TLS Error: Unroutable control packet received from [AF_INET]123.123.123.123:1194 (si=3 op=P_ACK_V1)
Tue Jul  2 13:26:35 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul  2 13:26:36 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul  2 13:26:36 2013 TLS Error: Unroutable control packet received from [AF_INET]123.123.123.123:1194 (si=3 op=P_ACK_V1)
Tue Jul  2 13:26:37 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul  2 13:26:39 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul  2 13:26:39 2013 [UNDEF] Inactivity timeout (--ping-restart), restarting

через какое-то время может появиться вот это:

Код: Выделить всё

Tue Jul  2 13:26:53 2013 [vpnsrv] Inactivity timeout (--ping-restart), restarting
Tue Jul  2 13:26:53 2013 TCP/UDP: Closing socket
Tue Jul  2 13:26:53 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Jul  2 13:26:53 2013 Restart pause, 2 second(s)
Tue Jul  2 13:26:55 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul  2 13:26:55 2013 Re-using SSL/TLS context
Tue Jul  2 13:26:55 2013 LZO compression initialized
Tue Jul  2 13:26:55 2013 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Jul  2 13:26:55 2013 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Jul  2 13:26:55 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jul  2 13:26:55 2013 Local Options hash (VER=V4): '504e774e'
Tue Jul  2 13:26:55 2013 Expected Remote Options hash (VER=V4): '14168603'
Tue Jul  2 13:26:55 2013 UDPv4 link local (bound): [undef]
Tue Jul  2 13:26:55 2013 UDPv4 link remote: [AF_INET]123.123.123.123:1194
Tue Jul  2 13:26:55 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul  2 13:26:55 2013 TLS: Initial packet from [AF_INET]123.123.123.123:1194, sid=26a24dd3 c75415a2
Tue Jul  2 13:26:55 2013 VERIFY OK: depth=1, /C=RU/ST=MSK/L=Moscow/O=EGA/OU=IT/CN=vpnsrv/name=vpnsrv/emailAddress=postmaster
Tue Jul  2 13:26:55 2013 VERIFY OK: nsCertType=SERVER
Tue Jul  2 13:26:55 2013 VERIFY OK: depth=0, /C=RU/ST=MSK/L=Moscow/O=EGA/OU=IT/CN=vpnsrv/name=vpnsrv/emailAddress=postmaster
Tue Jul  2 13:26:55 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul  2 13:26:55 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul  2 13:26:55 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul  2 13:26:55 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul  2 13:26:55 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jul  2 13:26:55 2013 [vpnsrv] Peer Connection Initiated with [AF_INET]123.123.123.123:1194
Tue Jul  2 13:26:56 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:26:57 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:26:57 2013 SENT CONTROL [vpnsrv]: 'PUSH_REQUEST' (status=1)
Tue Jul  2 13:26:57 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:26:59 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:26:59 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:26:59 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:27:00 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul  2 13:27:01 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed

В общем, факт в том, что разорванное соединение автоматически не восстанавливается, как по идее должно быть при использовании параметра "keepalive".

Конфиг сервера:

Код: Выделить всё

mode server
local 123.123.123.123
port 1194
proto udp
dev tun1
management 192.168.0.2 8330
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh2048.pem
server 10.1.1.0 255.255.255.0
topology subnet
ifconfig-pool-persist /usr/local/etc/openvpn/ipp1.txt 3600
push "dhcp-option DNS 192.168.1.250"
push "dhcp-option DOMAIN company.ru"
client-config-dir ccd
route 192.168.10.0 255.255.255.0 10.1.1.1
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth SHA1
cipher BF-CBC
keepalive 1 5
comp-lzo
max-clients 100
user nobody
group nobody
persist-key
persist-tun
persist-local-ip
persist-remote-ip
push "persist-key"
push "persist-tun"
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
mute 20

конфиг клиента:

Код: Выделить всё

dev tun0
proto udp
remote 123.123.123.123
port 1194
client
auth-user-pass /etc/openvpn/passwd
resolv-retry infinite
pkcs12 /etc/openvpn/vpnsrv/sklad.p12
tls-client
tls-auth /etc/openvpn/vpnsrv/ta.key 1
auth SHA1
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

Если на клиенте сервис openvpn остановить, подождать, пока на стороне сервера соединение сбросится и снова его запустить, то связь восстанавливается.

Посмотрите пожалуйста свежим взглядом, может что-то не так в настройках. Есть у меня подозрение, что дело в каких-то таймаутах или чём-то подобном.

И второй момент. Пока я боролся с этой проблемой, решил, как временное решение написать скрипт, который по отсутствию пинга нужного адреса будет останавливать, а потом снова запускать сервис openvpn.
Скрипт выглядит так:

Код: Выделить всё

#!/bin/bash

testip="192.168.1.250"

kol=$(/bin/ping -c 4 $testip | grep "received" | awk '{print $4}')
if [ $kol == 0 ]
    then
    echo "No ping to dc02. Waiting for 30 seconds..." | logger -t OPENVPNTEST
    sleep 30
    kol=$(/bin/ping -c 4 $testip | grep "received" | awk '{print $4}')
        if [ $kol == 0 ]
            then
                echo "Restarting OpenVPN... " | logger -t OPENVPNTEST
                echo "Stop OpenVPN service. " | logger -t OPENVPNTEST
                /etc/init.d/openvpn stop | logger -t OPENVPNTEST
                sleep 30
                echo "Start OpenVPN service. " | logger -t OPENVPNTEST
                /etc/init.d/openvpn start | logger -t OPENVPNTEST
                sleep 5
                /etc/init.d/openvpn status | logger -t OPENVPNTEST
                exit 0
        fi
fi

Проблема в том, что когда я этот скрипт запускаю вручную, то всё работает, а когда вставляю его в cron на выполнение через каждые 5 минут, то сервис openvpn останавливается, а вот запускаться обратно не хочет. Просто, не выдавая никаких ошибок, не стартует и всё. Последняя строка "/etc/init.d/openvpn status" выдаёт в лог VPN is not running.
Система ubuntu server 12.04. Скрипт запускаю из под рута. В чём тут может быть засада?

Хостинг HostFood.ru · **Хостинг HostFood.ru**

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-03 22:57:06

Дата? ppoe? пару провайдеров на клиенте или сервере?

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-04 10:04:52

Не совсем понял вопросы, но попытаюсь объяснить, как всё это устроено.
OpenVPN поднят для удалённой работы сотрудников с серверами главного офиса компании через RDP и SMB. В данном случае приведены логи и конфиг удалённого офиса, сеть которого соединена с главным через OpenVPN. Кроме этого, постоянного соединения, сервер держит ещё пару десятков периодически создаваемых туннелей от отдельных сотрудников, работающих из дома. К серверу подсоединено два провайдера, но для каждого поднят отдельный демон OpenVPN, слушающий на своём интерфейсе. Пользователи раскидываются по провайдерам случайным образом более-менее равномерно.

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-04 10:09:52

Маршрутизация симетричная? Есть подозрение что при инициализации соединения запросы приходят на 1й интерфейс, а ответы уходят через второй (или с другим src). Все предположения условны - надо смотреть на трафик в моменты появления ошибок. Думаю проблема именно в "двух провайдерах", а именно в dst и src приходящих-уходящих ответов.
Ну и как вариант - в на разные интерфейсы (демоны) толкаете адреса из одного опенвпн-пула. Вот тут могут тоже быть приключения с определением на вашем сервере маршрутов к конкретным клиентам.
З.ы. Фейковые адреса аля 123.123.123.123 - не вкусные к восприятию.

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-04 10:54:58

Маршрутизация сделана через setfib и она, как бы, работает. Да и если бы была проблема в маршрутизации, то оно бы вообще не работало, а проблема в том, что openvpn-канал большую часть времени прекрасно функционирует (может неделю висеть не разрываясь), но иногда рвётся и происходит описанный эффект. Как я написал выше, проблему решает перезапуск сервиса OpenVPN на стороне клиента.
Я погуглил по теме. Есть подозрение, что суть проблемы кроется в протоколе UDP. На каком-то из форумов поддержки OpenVPN было написано примерно следующее: Т.к. протокол UDP не имеет средств контроля наличия соединения, то при кратковременном разрыве связи (например, по вине провайдера), туннель прерывается. При попытке его восстановить и происходят эти коллизии с невозможностью обмена ключами. Говорят, что на TCP такого эффекта нет, но я TCP пробовал, с ним скорость ощутимо меньше.

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-04 11:06:02

Это бред. Функционирует исправно. крест на пузе. Проблем с ключами не было никогда, за исключение рассинхронизации времени.
Все же попробуйте задвинуть все на один интерфейс.

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-04 11:23:17

А какая рассинхронизация времени критична?

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-04 11:34:38

рассинхронизация, когда у клиента батарейка села и в бивисе дата сбросилась до даты "раньше чем создан сертификат"

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-04 11:39:04

Ну, это исключено. А чтобы задвинуть всё на один интерфейс, придётся поднимать второй сервер, т.к. одного канала мало.

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-04 11:49:49

tcpdump в руки, vebrose повыше и анализируйте. Панацеи нет. Работает 60 филиалов + ~100 бегающих манагеров.

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-04 12:01:17

Может вы подскажете, какие оптимально ставить tls-timeout и значения параметра keepalive? А то я никак не могу подобрать, чтобы работало нормально. Проблема в том, что когда соединение рвётся, то клиент пытается переподключиться, когда разорванное соединение ещё не сброшено сервером.

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-04 12:04:01

tcpdump в руки, vebrose повыше и анализируйте. Панацеи нет. Работает 60 филиалов + ~100 бегающих манагеров.
сервер

Код: Выделить всё

tls-timeout 120
keepalive 10 120
max-clients 254
mssfix
float
verb 3

клиент

Код: Выделить всё

mssfix
ping-restart 180
persist-key
persist-tun

Jeque · Непрочитанное сообщение **Jeque** » 2013-07-08 10:09:40

Два вопроса, если можно:
По какой причине вы указали "tls-timeout 120"? Что даёт эта цифра в отличие от умолчальных двух секунд?
Зачем вы используете параметр mssfix без значения? Это ведь аналогично выставлению его по-умолчанию. Или у вас ещё и fragment как-то выставлен?

mak_v_ · Непрочитанное сообщение **mak_v_** » 2013-07-08 12:43:52

--tls-timeout n
Packet retransmit timeout on TLS control channel if no acknowledgment from remote within n seconds (default=2). When OpenVPN sends a control packet to its peer, it will expect to receive an acknowledgement within n seconds or it will retransmit the packet, subject to a TCP-like exponential backoff algorithm. This parameter only applies to control channel packets. Data channel packets (which carry encrypted tunnel data) are never acknowledged, sequenced, or retransmitted by OpenVPN because the higher level network protocols running on top of the tunnel such as TCP expect this role to be left to them.

1) На нестойких соединениях (3ж мопеды, латентные соединения (аля воздух на 5 км)) - увеличиваем время на установку соединения.
2) mssfix на клиентах\серверах выставлен по разному (для pptp, ppoe), хотя и без этого ферментированные пакеты будут работать, если не задумано другого.

Ещё раз - поставьте vebrose повыше в конфигах и логи в студию (не забыв погрепать от мусора)

Гость

Ну, вот, посмотри, может тебе пригодится http://digitalshock.ru/%d1%88%d0%b8%d1% ... 81-openvpn

forum.lissyara.su

Проблемы с OpenVPN

Проблемы с OpenVPN

Услуги хостинговой компании Host-Food.ru

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN

Re: Проблемы с OpenVPN