LINUX.ORG.RU
Форум — Admin  

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



Последнее исправление: dTinside (всего исправлений: 1)
← Cisco <-> Linux туннель GRE + IPSEC
Wildcard DNS →
Ответ на: комментарий от 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

Ты таблицу 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
()
21 мая 2014 г.

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

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
()
27 февраля 2015 г.

дату проверь

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

дату проверь

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

cynic
()
29 марта 2015 г.

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

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

vsafonin ★
()
6 октября 2015 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Cisco <-> Linux туннель GRE + IPSEC
Admin
Wildcard DNS →