LINUX.ORG.RU

OpenServer Ошибки с обеих сторон.

 ,


0

1

Есть CentOS 6.5, на нём стоит OpenServer 2.3.2 в комплекте с Easy-RSA 2.0. Суть в том, что сервер запускается нормально, то есть в логе я вижу «Initialization Sequence Completed». Далее я на удалённой машине пытаюсь подключиться к серверу с клиента XP SP3 (через OpenVPN-GUI 2.0.9). Схема работы такая:

Клиент -> Роутер с NAT (1194->1194 сервера) -> Сервер
. Итак, проблемы (Оставил только ошибки). На клиенте
Wed Dec 04 12:52:21 2013 us=109151 VERIFY ERROR: depth=1, error=certificate signature failure: /C=RU/ST=RO/L=*****/O=*****/OU=*****/CN=NITELaB_CA/name=EasyRSA/emailAddress=*****
Wed Dec 04 12:52:21 2013 us=111888 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Dec 04 12:52:21 2013 us=113361 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 04 12:52:21 2013 us=114200 TLS Error: TLS handshake failed
Через некоторое время
Wed Dec 04 12:52:25 2013 us=739951 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 12:52:25 2013 us=740888 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 12:52:26 2013 us=977402 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 12:52:26 2013 us=978382 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
В этот момент на сервере (Время последней хрени)
Wed Dec  4 12:54:20 2013 us=466053 IP_CLIENT:29011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Dec  4 12:54:20 2013 us=466122 IP_CLIENT:29011 TLS Error: TLS handshake failed
Wed Dec  4 12:54:20 2013 us=466250 IP_CLIENT:29011 SIGUSR1[soft,tls-error] received, client-instance restarting
Все сертификаты перевыпускал уже 10 раз - ничего не меняется.

На сервере в IPTABLES открыт UDP 1194, SeLinux отключен. Конфиг сервера

port 1194
proto udp
dev tun0
ca "/etc/openvpn/keys/ca.crt"
cert "/etc/openvpn/keys/server.crt"
key "/etc/openvpn/keys/server.key"
dh "/etc/openvpn/keys/dh1024.pem"
server 10.70.80.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway"
keepalive 10 60
tls-auth "/etc/openvpn/keys/ta.key" 0
cipher AES-128-CBC
comp-lzo
max-clients 5
user nobody
group nobody
persist-key
persist-tun
status "/var/log/openvpn/openvpn-status.log"
log "/var/log/openvpn/openvpn.log"
log-append "/var/log/openvpn/openvpn.log"
verb 4
Конфиг Win-клиента
client 
proto udp 
dev tun 
dev-node TAP-Win32 Adapter V8 //Название адаптера в диспетчере
remote IP_SERVER
resolv-retry infinite
ca "C:\\OpenVPN\\ssl\\ca.crt"
cert "C:\\OpenVPN\\ssl\\nlbout.crt"
key "C:\\OpenVPN\\ssl\\nlbout.key"
ns-cert-type server
tls-auth "C:\\OpenVPN\\ssl\\ta.key" 1
cipher AES-128-CBC
comp-lzo
verb 4

Что скажет

openssl verify -CAfile ca.crt client.crt

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

Вообще для меня тёмным пятном осталась настройка IPTABLES. Достаточно только открыть порт или необходимы ещё какие-то действия?

dTinside ()

Ещё попробуй временно убрать tls-auth, в конфиге клиента client заменить на pull, а в конфиге сервера server заменить на

mode server
ifconfig 10.70.80.1 255.255.255.0
push «route-gateway 10.70.80.1»

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

Роутер с NAT (1194->1194 сервера)

Это должен быть DNAT. На всякий случай покажи iptables. Судя по тому, что клиент с сервером начали общаться - сделано правильно

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

Сделав данные действия получил в логе сервера

Options error: --mode server requires --tls-server
То есть нужно оставить что-то одно.

dTinside ()
Ответ на: комментарий от selivan

Ситуация такова: и в сервере, и на клиенте закоментировал строчки

tls-auth "/etc/openvpn/keys/ta.key" 0
tls-auth "C:\\OpenVPN\\ssl\\ta.key" 1
появилось сообщение
Клиент: cannot locate HMAC in incoming packet from 9
Сервер: TLS Error: reading acknowledgement record from packet

IPTABLES

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -p udp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 137 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 138 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 139 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 445 -j ACCEPT

-A INPUT -m state --state NEW -p udp --dport 123 -j ACCEPT

-A INPUT -m state --state NEW -p udp --dport 1194 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

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

Ошибка с TLS_ERROR: BIO read tls_read_plaintext error: появляется через раз, но вот с

TLS Error: Unroutable control packet received from IP_SERVER:1194
идёт всё время.

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

Это при текущей секции server

server 10.70.80.0 255.255.255.0
ifconfig 10.70.80.1 255.255.255.0
push «route-gateway 10.70.80.1»

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

Ты таблицу filter показал, а нужна ещё nat. Это iptables на роутере или на сервере? Я про роутер спрашивал

Опять встречаю iptables, настроенные в стиле pf - POLICY ACCEPT, и последнее правило DROP или REJECT. Почему не делать DROP/REJECT в POLICY? Удобнее же - можно просто добавлять новые правила, не контролируя, чтобы они встаил перед последним.

Как я понимаю, ошибка возникает из-за использования TLS Auth. Надо его отключить и попробовать установить соединение без него, а потом уже пробовать включить обратно. За него отвечает опция tls-auth, а ещё client и server раскрываются в несколько других опций, в том числе tls-client и tls-server. Надо как-то их убрать

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

server надо заменить на ifconfig ... и что-то там ещё, потому что он раскрывается в tls-server, а мы пока пробуем завестись без tls auth.

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

после строки
tls-auth «C:\\OpenVPN\\ssl\\ta.key» 1
на клиенте попробуйте прописать
auth MD5

braindef ()
Ответ на: комментарий от selivan

IPTABLES, кроме портов, остался в том виде, в котором он идёт по дэфолту в СэнтОСе. IPTABLES я еще не постиг. Это IPTABLES на самом сервере VPN, на роутере (Asus RT-12N) просто идёт проброс с 1194 внешки на 1194 сервера.

TLS я вроде бы везде убрал. Я много поменял, уже немного запутался, поэтому еще раз выкладываю всё происходящее. Сервер:

port 1194
proto udp
dev tun0
tun-mtu 1500
ca "/etc/openvpn/keys/ca.crt"
cert "/etc/openvpn/keys/server.crt"
key "/etc/openvpn/keys/server.key"
dh "/etc/openvpn/keys/dh1024.pem"
server 10.70.80.0 255.255.255.0
ifconfig 10.70.80.1 255.255.255.0
push «route-gateway 10.70.80.1»
ifconfig-pool-persist ipp.txt
push "redirect-gateway"
keepalive 10 60
cipher AES-128-CBC
comp-lzo
max-clients 5
user nobody
group nobody
persist-key
persist-tun
status "/var/log/openvpn/openvpn-status.log"
log "/var/log/openvpn/openvpn.log"
log-append "/var/log/openvpn/openvpn.log"
verb 4
Клиент:
client
proto udp 
dev tun 
dev-node TAP-Win32 Adapter V8
remote IP_SERVER
resolv-retry infinite
ca "C:\\OpenVPN\\ssl\\ca.crt"
cert "C:\\OpenVPN\\ssl\\client.crt"
key "C:\\OpenVPN\\ssl\\client.key"
ns-cert-type server
cipher AES-128-CBC
keepalive 10 60
comp-lzo
verb 4
mssfix
tun-mtu 1500

Запуск сервера

Wed Dec 04 15:27:56 2013 us=36454 VERIFY ERROR: depth=1, error=certificate signature failure: /C=RU/ST=RO/L=TaganYork/O=NITELaB/OU=Maintenance/CN=NITELaB_CA/name=EasyRSA/emailAddress=mail@nitelab.ru
Wed Dec 04 15:27:56 2013 us=36585 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Dec 04 15:27:56 2013 us=36604 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 04 15:27:56 2013 us=36617 TLS Error: TLS handshake failed
Wed Dec 04 15:27:56 2013 us=36958 TCP/UDP: Closing socket
Wed Dec 04 15:27:56 2013 us=37040 SIGUSR1[soft,tls-error] received, process restarting
Wed Dec 04 15:27:56 2013 us=37056 Restart pause, 2 second(s)
Wed Dec 04 15:27:58 2013 us=32254 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Wed Dec 04 15:27:58 2013 us=32868 LZO compression initialized
Wed Dec 04 15:27:58 2013 us=32901 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Dec 04 15:27:58 2013 us=34714 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Dec 04 15:27:58 2013 us=34755 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Dec 04 15:27:58 2013 us=34762 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Dec 04 15:27:58 2013 us=34782 Local Options hash (VER=V4): '66096c33'
Wed Dec 04 15:27:58 2013 us=34791 Expected Remote Options hash (VER=V4): '691e95c7'
Wed Dec 04 15:27:58 2013 us=34804 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Dec 04 15:27:58 2013 us=35256 UDPv4 link local (bound): [undef]:1194
Wed Dec 04 15:27:58 2013 us=35279 UDPv4 link remote: IP_SERVER:1194
Wed Dec 04 15:27:58 2013 us=178343 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 15:27:58 2013 us=179685 TLS: Initial packet from IP_SERVER:1194, sid=c5928e60 a872b8e6
Wed Dec 04 15:27:58 2013 us=608081 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 15:27:58 2013 us=651458 VERIFY ERROR: depth=1, error=certificate signature failure: /C=RU/ST=RO/L=TaganYork/O=NITELaB/OU=Maintenance/CN=NITELaB_CA/name=EasyRSA/emailAddress=mail@nitelab.ru
Wed Dec 04 15:27:58 2013 us=651575 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Dec 04 15:27:58 2013 us=651593 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 04 15:27:58 2013 us=651606 TLS Error: TLS handshake failed
Wed Dec 04 15:27:58 2013 us=651817 TCP/UDP: Closing socket
Wed Dec 04 15:27:58 2013 us=651876 SIGUSR1[soft,tls-error] received, process restarting
Wed Dec 04 15:27:58 2013 us=651885 Restart pause, 2 second(s)
Wed Dec 04 15:28:00 2013 us=646029 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Wed Dec 04 15:28:00 2013 us=648445 LZO compression initialized
Wed Dec 04 15:28:00 2013 us=648526 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Dec 04 15:28:00 2013 us=649522 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Dec 04 15:28:00 2013 us=649663 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Dec 04 15:28:00 2013 us=649678 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Dec 04 15:28:00 2013 us=649702 Local Options hash (VER=V4): '66096c33'
Wed Dec 04 15:28:00 2013 us=649722 Expected Remote Options hash (VER=V4): '691e95c7'
Wed Dec 04 15:28:00 2013 us=649758 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Dec 04 15:28:00 2013 us=649778 UDPv4 link local (bound): [undef]:1194
Wed Dec 04 15:28:00 2013 us=649811 UDPv4 link remote: IP_SERVER:1194
Wed Dec 04 15:28:00 2013 us=798150 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)

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

В этот момент на сервере

Wed Dec  4 15:28:01 2013 us=196933 IP_CLIENT:1644 TLS: new session incoming connection from IP_CLIENT:1644
Wed Dec  4 15:28:55 2013 us=435732 IP_CLIENT:1644 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Dec  4 15:28:55 2013 us=435799 IP_CLIENT:1644 TLS Error: TLS handshake failed
Wed Dec  4 15:28:55 2013 us=435961 IP_CLIENT:1644 SIGUSR1[soft,tls-error] received, client-instance restarting
Wed Dec  4 15:28:55 2013 us=568440 MULTI: multi_create_instance called
Wed Dec  4 15:28:55 2013 us=568525 IP_CLIENT:1644 Re-using SSL/TLS context
Wed Dec  4 15:28:55 2013 us=568576 IP_CLIENT:1644 LZO compression initialized
Wed Dec  4 15:28:55 2013 us=568652 IP_CLIENT:1644 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Dec  4 15:28:55 2013 us=568678 IP_CLIENT:1644 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Dec  4 15:28:55 2013 us=568717 IP_CLIENT:1644 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Dec  4 15:28:55 2013 us=568737 IP_CLIENT:1644 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Dec  4 15:28:55 2013 us=568764 IP_CLIENT:1644 Local Options hash (VER=V4): '691e95c7'
Wed Dec  4 15:28:55 2013 us=568788 IP_CLIENT:1644 Expected Remote Options hash (VER=V4): '66096c33'
Wed Dec  4 15:28:55 2013 us=568837 IP_CLIENT:1644 TLS: Initial packet from 95.153.193.107:1644, sid=2d31d721 3867fdd4
Wed Dec  4 15:28:56 2013 us=69122 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:56 2013 us=87755 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:56 2013 us=109065 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:57 2013 us=517561 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:58 2013 us=46952 IP_CLIENT:1644 TLS: new session incoming connection from IP_CLIENT:1644
Wed Dec  4 15:28:58 2013 us=528654 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:58 2013 us=567809 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:58 2013 us=587652 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:28:59 2013 us=958066 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Wed Dec  4 15:29:00 2013 us=518194 IP_CLIENT:1644 TLS: new session incoming connection from IP_CLIENT:1644
Wed Dec  4 15:29:55 2013 us=18240 IP_CLIENT:1644 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Dec  4 15:29:55 2013 us=18387 IP_CLIENT:1644 TLS Error: TLS handshake failed
Wed Dec  4 15:29:55 2013 us=18722 IP_CLIENT:1644 SIGUSR1[soft,tls-error] received, client-instance restarting
Wed Dec  4 15:29:55 2013 us=258087 MULTI: multi_create_instance called
Wed
Ещё я читал про синхронизацию времени. Насколько точной она должна быть?

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

Опять та же фигня:

VERIFY ERROR: depth=1, error=certificate signature failure: /C=RU/ST=RO/L=TaganYork/O=NITELaB/OU=Maintenance/CN=NITELaB_CA/name=EasyRSA/emailAddress=mail@nitelab.ru
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Попробуй ещё dh убрать, он только для tls auth нужен. И ns-cert-type.

Вообще хз, сильно думать надо. Вечером ещё посмотрю

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

Если есть возможность — пересоздай сертификаты са, сервера и клиента (все ранее выпущенные серты станут не действительны!).

BOOBLIK ()
Ответ на: комментарий от dTinside

Запуск сервера ... Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'

Ты точно делал сертификат сервера через скрипт ./build-key- server?

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

Пересоздание не помогает. Все-таки многие форумы указывают на синхронизацию времени, насколько она должна быть точной? Разница в полсекунды критична? Еще как вариант писали что такой глюк только в 2.3.2, поставил 2.2.2 - трабла осталась.

dTinside ()
Ответ на: комментарий от BOOBLIK

Да,

. ./vars
./clean-all
./build-ca
./build-key-server server
./build-key client
./build-dh
Вот еще конфиг изи-рса

export EASY_RSA="/etc/openvpn/easy-rsa/2.0"
export OPENSSL="openssl"
export PKCS11TOOL="pkcs11-tool"
export GREP="grep"
export KEY_CONFIG="/etc/openvpn/easy-rsa/2.0/openssl-1.0.0.cnf"
export KEY_DIR="/etc/openvpn/keys"
# PKCS11 fixes
export PKCS11_MODULE_PATH="dummy"
export PKCS11_PIN="dummy"
export KEY_SIZE=1024
# In how many days should the root CA key expire?
export CA_EXPIRE=3650
# In how many days should certificates expire?
export KEY_EXPIRE=3650
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="RO"
export KEY_CITY="TaganYork"
export KEY_ORG="NITELaB"
export KEY_EMAIL="mail@nitelab.ru"
export KEY_OU="Maintenance"
# X509 Subject Field
export KEY_NAME="EasyRSA"
# PKCS11 Smart Card
# export PKCS11_MODULE_PATH="/usr/lib/changeme.so"
# export PKCS11_PIN=1234
# If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below
# You will also need to make sure your OpenVPN server config has the duplicate-cn option set
# export KEY_CN="CommonName"

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

Нет, разница в пару секунд (да даже пару дней, если серты валидны по отношению к дате в системе) не критична.

BOOBLIK ()
Ответ на: комментарий от dTinside

Было бы еще неплохо увидеть строки вида:

Validity
            Not Before: May 24 20:05:58 2013 GMT
            Not After : May 22 20:05:58 2023 GMT
из файлов ca.crt, server.crt, client.crt

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

ca

 Validity
            Not Before: Dec  4 10:53:18 2013 GMT
            Not After : Dec  2 10:53:18 2023 GMT
server
Validity
            Not Before: Dec  4 10:54:22 2013 GMT
            Not After : Dec  2 10:54:22 2023 GMT
client
        Validity
            Not Before: Dec  4 10:54:59 2013 GMT
            Not After : Dec  2 10:54:59 2023 GMT

dTinside ()

Лень через всё продираться, вот моё точно работающее:

сервер:

port 1194
proto udp
dev tun
link-mtu 1400
tun-mtu-extra 32
mssfix 1372
server 192.168.253.0 255.255.255.0
ifconfig-pool-persist /var/lib/openvpn/ipp.txt
client-config-dir /etc/openvpn/cc
client-to-client
route x.x.x.x 255.255.0.0
push "route x.x.x.x 255.255.0.0"
route y.y.y.y 255.255.0.0
push "route y.y.y.y 255.255.0.0"
route z.z.z.z
keepalive 10 120
max-clients 48
persist-key
persist-tun
status /var/lib/openvpn/openvpn-status.log
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/certs/server.key
dh /etc/openvpn/certs/dh1024.pem
verb 1
max-routes-per-client 16

(«max-clients» какой-то пережиток прошлого, надо будет убрать, «client-to-client» - по вкусу)

клиент:

client
dev tun
proto udp
remote <SERVER-NAME-OR-ADDRESS> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
ca ca.crt
cert client.crt
key client.key
verb 3

выдержка из iptables:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A FORWARD -i tun+ -o eth2.254 -j ACCEPT
-A FORWARD -i tun+ -o eth2.2 -j ACCEPT
-A FORWARD -i tun+ -o tun+ -j ACCEPT
-A FORWARD -i eth2.2 -o tun+ -j ACCEPT
-A FORWARD -i eth2.254 -o tun+ -j ACCEPT
-A FORWARD -s x.x.x.x/255.255.192.192 -i tun+ -j ACCEPT
-A FORWARD -s 192.168.253.0/24 -i tun+ -j ACCEPT
berrywizard ★★★★★ ()

возьми client.conf и server.conf из /usr/share/doc/openvpn-какаятамверсия/sample/sample-config-files/

anonymous ()

проблема в шифровании

eyasy-rsa в зависимости от установленной у вас версии цепляет файлы openssl-1.0.0.cnf openssl-0.9.8.cnf openssl-0.9.6.cnf исправьте в них метод шифрования с sha256 на md5 default_md = md5 синхронизируйте время на сервере и клиенте http://obafgkm-stars.ya.ru/replies.xml?item_no=114

с настройками указаннами тут http://unixblog.org.ua/openvpn/configure-opevpn-on-centos-6-install-openvpn/

у меня все заработало

canon90 ()

дату проверь

сертификаты нормальные, коннекты тоже

дату проверь

такое бывает, когда время на клиенте убегает вперёд от времени сервера где серты генерились

cynic ()

У меня похожая проблема, решилась заменой виндового клиента

Столкнулся с похожей проблемой, что только не отключал, сертификаты раз 20 пересоздавал, отключал всякие настройки и так далее... только одно но - Linux машине все хорошо, работает. На Windows клиентах нет.. в итоге решилось все проще простого - установкой этого дистрибутива OpenVPN

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