LINUX.ORG.RU
ФорумAdmin

Прошу помощи с OpenVPN


1

1

цель соединить две сети. есть два сервера под ClearOS 6.3

основной офис с подсетью 192.168.0.0/24 и шлюзом с OpenVpn в роли сервера 192.168.0.250 Второй офис c подсетью 192.168.0.2/24 и шлюзом с Openvpn в роли клиента

Иногда коннект происходит и из сети за клиентом пингуется сеть основного офиса. при проблемах в подключении лог клиента выглядит так:

Tue Mar 26 12:31:37 2013 OpenVPN 2.2.1 i386-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Sep 12 2011
Tue Mar 26 12:31:37 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:31:37 2013 WARNING: file '/etc/openvpn/new/client-st1g-key.pem' is group or others accessible
Tue Mar 26 12:31:37 2013 LZO compression initialized
Tue Mar 26 12:31:37 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:31:37 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:31:37 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:31:37 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:31:37 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:31:37 2013 UDPv4 link local: [undef]
Tue Mar 26 12:31:37 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:31:37 2013 TLS: Initial packet from XX.XX.XX.XX:1194, sid=89a598f9 f7366aa5
Tue Mar 26 12:31:37 2013 VERIFY OK: depth=1, /C=RU/L=Krasnodar/O=ClearOS/OU=grand/CN=ca.clearos.grand.com/emailAddress=security@clearos.grand.com/O=grand/ST=Krasnodar
Tue Mar 26 12:31:37 2013 VERIFY OK: nsCertType=SERVER
Tue Mar 26 12:31:37 2013 VERIFY OK: depth=0, /C=RU/ST=Krasnodar/L=Krasnodar/O=ClearOS/O=grand/OU=grand/CN=clearos.grand.com/emailAddress=security@clearos.grand.com
Tue Mar 26 12:31:37 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:31:37 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:31:37 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:31:37 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:31:37 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar 26 12:31:37 2013 [clearos.grand.com] Peer Connection Initiated with XX.XX.XX.XX:1194
Tue Mar 26 12:31:40 2013 SENT CONTROL [clearos.grand.com]: 'PUSH_REQUEST' (status=1)
Tue Mar 26 12:31:40 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.0.250,dhcp-option WINS ,dhcp-option DOMAIN grand.com,route 192.168.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: route options modified
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Mar 26 12:31:40 2013 ROUTE default_gateway=192.168.1.1
Tue Mar 26 12:31:40 2013 TUN/TAP device tun0 opened
Tue Mar 26 12:31:40 2013 TUN/TAP TX queue length set to 100
Tue Mar 26 12:31:40 2013 /sbin/ip link set dev tun0 up mtu 1500
Tue Mar 26 12:31:40 2013 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Tue Mar 26 12:31:40 2013 /sbin/ip route add 192.168.0.0/24 via 10.8.0.5
Tue Mar 26 12:31:40 2013 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Tue Mar 26 12:31:40 2013 Initialization Sequence Completed
Tue Mar 26 12:33:40 2013 [clearos.grand.com] Inactivity timeout (--ping-restart), restarting
Tue Mar 26 12:33:40 2013 TCP/UDP: Closing socket
Tue Mar 26 12:33:40 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Mar 26 12:33:40 2013 Restart pause, 2 second(s)
Tue Mar 26 12:33:42 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:33:42 2013 Re-using SSL/TLS context
Tue Mar 26 12:33:42 2013 LZO compression initialized
Tue Mar 26 12:33:42 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:33:42 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:33:42 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:33:42 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:33:42 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:33:42 2013 UDPv4 link local: [undef]
Tue Mar 26 12:33:42 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:34:42 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:34:42 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:34:42 2013 TCP/UDP: Closing socket
Tue Mar 26 12:34:42 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:34:42 2013 Restart pause, 2 second(s)
Tue Mar 26 12:34:44 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:34:44 2013 Re-using SSL/TLS context
Tue Mar 26 12:34:44 2013 LZO compression initialized
Tue Mar 26 12:34:44 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:34:44 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:34:44 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:34:44 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:34:44 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:34:44 2013 UDPv4 link local: [undef]
Tue Mar 26 12:34:44 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:35:45 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:35:45 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:35:45 2013 TCP/UDP: Closing socket
Tue Mar 26 12:35:45 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:35:45 2013 Restart pause, 2 second(s)
Tue Mar 26 12:35:47 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:35:47 2013 Re-using SSL/TLS context
Tue Mar 26 12:35:47 2013 LZO compression initialized
Tue Mar 26 12:35:47 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:35:47 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:35:47 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:35:47 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:35:47 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:35:47 2013 UDPv4 link local: [undef]
Tue Mar 26 12:35:47 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:36:47 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:36:47 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:36:47 2013 TCP/UDP: Closing socket
Tue Mar 26 12:36:47 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:36:47 2013 Restart pause, 2 second(s)
Tue Mar 26 12:36:49 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:36:49 2013 Re-using SSL/TLS context
Tue Mar 26 12:36:49 2013 LZO compression initialized
Tue Mar 26 12:36:49 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:36:49 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:36:49 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:36:49 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:36:49 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:36:49 2013 UDPv4 link local: [undef]
Tue Mar 26 12:36:49 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:36:49 2013 TLS: Initial packet from XX.XX.XX.XX:1194, sid=7444d74a 473b1a1f
Tue Mar 26 12:36:49 2013 VERIFY OK: depth=1, /C=RU/L=Krasnodar/O=ClearOS/OU=grand/CN=ca.clearos.grand.com/emailAddress=security@clearos.grand.com/O=grand/ST=Krasnodar
Tue Mar 26 12:36:49 2013 VERIFY OK: nsCertType=SERVER
Tue Mar 26 12:36:49 2013 VERIFY OK: depth=0, /C=RU/ST=Krasnodar/L=Krasnodar/O=ClearOS/O=grand/OU=grand/CN=clearos.grand.com/emailAddress=security@clearos.grand.com
Tue Mar 26 12:36:49 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:36:49 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:36:49 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:36:49 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:36:49 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar 26 12:36:49 2013 [clearos.grand.com] Peer Connection Initiated with XX.XX.XX.XX:1194
Tue Mar 26 12:36:52 2013 SENT CONTROL [clearos.grand.com]: 'PUSH_REQUEST' (status=1)
Tue Mar 26 12:36:52 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.0.250,dhcp-option WINS ,dhcp-option DOMAIN grand.com,route 192.168.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: route options modified
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Mar 26 12:36:52 2013 Preserving previous TUN/TAP instance: tun0
Tue Mar 26 12:36:52 2013 Initialization Sequence Completed
Tue Mar 26 12:38:47 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:47 2013 TLS Error: reading acknowledgement record from packet
Tue Mar 26 12:38:47 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:47 2013 VERIFY OK: depth=1, /C=RU/L=Krasnodar/O=ClearOS/OU=grand/CN=ca.clearos.grand.com/emailAddress=security@clearos.grand.com/O=grand/ST=Krasnodar
Tue Mar 26 12:38:47 2013 VERIFY OK: nsCertType=SERVER
Tue Mar 26 12:38:47 2013 VERIFY OK: depth=0, /C=RU/ST=Krasnodar/L=Krasnodar/O=ClearOS/O=grand/OU=grand/CN=clearos.grand.com/emailAddress=security@clearos.grand.com
Tue Mar 26 12:38:47 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:38:47 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:38:47 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:38:47 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:38:47 2013 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Tue Mar 26 12:38:47 2013 TLS: tls_multi_process: untrusted session promoted to semi-trusted
Tue Mar 26 12:38:47 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar 26 12:38:49 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:49 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:54 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:39:03 2013 TLS Error: reading acknowledgement record from packet
Tue Mar 26 12:39:04 2013 TLS Error: Unroutable control packet received from XX.XX.XX.XX:1194 (si=3 op=P_ACK_V1)
Tue Mar 26 12:39:49 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:39:49 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:41:14 2013 [clearos.grand.com] Inactivity timeout (--ping-restart), restarting
Tue Mar 26 12:41:14 2013 TCP/UDP: Closing socket
Tue Mar 26 12:41:14 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Mar 26 12:41:14 2013 Restart pause, 2 second(s)
Tue Mar 26 12:41:16 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:41:16 2013 Re-using SSL/TLS context
Tue Mar 26 12:41:16 2013 LZO compression initialized
Tue Mar 26 12:41:16 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:41:16 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:41:16 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:41:16 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:41:16 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:41:16 2013 UDPv4 link local: [undef]
Tue Mar 26 12:41:16 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:42:16 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:42:16 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:42:16 2013 TCP/UDP: Closing socket
Tue Mar 26 12:42:16 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:42:16 2013 Restart pause, 2 second(s)
Tue Mar 26 12:42:18 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:42:18 2013 Re-using SSL/TLS context
Tue Mar 26 12:42:18 2013 LZO compression initialized
Tue Mar 26 12:42:18 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:42:18 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:42:18 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:42:18 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:42:18 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:42:18 2013 UDPv4 link local: [undef]
Tue Mar 26 12:42:18 2013 UDPv4 link remote: XX.XX.XX.XX:1194

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

port 1194
proto udp
dev tun
ca /etc/pki/CA/ca-cert.pem
cert /etc/pki/CA/sys-0-cert.pem
key /etc/pki/CA/private/sys-0-key.pem
dh /etc/openvpn/ssl/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
ifconfig-pool-persist /var/lib/openvpn/ipp.txt
status /var/lib/openvpn/openvpn-status.log
verb 3
push "dhcp-option DNS 192.168.0.250"
push "dhcp-option WINS "
push "dhcp-option DOMAIN grand.com"
push "route 192.168.0.0 255.255.255.0"

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

client
remote XX.XX.XX.XX 1194
dev tun
proto udp
nobind
keepalive 10 60
tls-timeout 15
persist-key
persist-tun
ca /etc/openvpn/new/ca-cert.pem
cert /etc/openvpn/new/client-st1g-cert.pem
key /etc/openvpn/new/client-st1g-key.pem
ns-cert-type server
comp-lzo
verb 3


Ответ на: комментарий от DALDON

нет конечно вторая сеть 192.168.2.0/24, у шлюза во второй сети ip 192.168.2.1 внутренний

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

пробовал tcp вместо udp?

Tue Mar 26 12:35:45 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Tue Mar 26 12:35:45 2013 TLS Error: TLS handshake failed

xtraeft ★★☆☆ ()
Ответ на: комментарий от post-factum

лишь бы не скатился до уровня мегабакса с брызганьем слюнями, а-ля «тсп говно, удп форева» без аргументов

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

пробовал, вроде по стабильней

А просто помониторить состояние коннективности между точками, мимо VPN ? Есть много разных вариантов, как результат icmp echo в какую-нибудь rrd писать.

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

при убогих каналах на удп далеко не уедешь

На любых каналах пофигу, потому что это всего лишь инкапсуляция.

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

проверял пингом, все нормально.

сейчас эту же ошибку TLS ERROR наблюдаю на виндовом машине которая на ходиться в основном офисе, то есть подключение по локальной сети до сервера

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

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

Надо было внимательно логи смотреть и прочие радости.

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

Надо было внимательно логи смотреть и прочие радости.
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

вот такое же было

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

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

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

еще пока был активным vpn туннель, была ошибка в которой было про mtu=1400, код ошибки 90, может кто пояснит как правильно прописать mtu-tun,mssfix? как я понял по умолчанию стоит mtu=1500,а mssfix=1450

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

была ошибка в которой было про mtu=1400, код ошибки 90, может кто пояснит как правильно прописать mtu-tun,mssfix? как я понял по умолчанию стоит mtu=1500,а mssfix=1450

А как два офиса видят друг друга? Имею ввиду физическую связность. Езернеты/адслы/вифи? Понизь мту, вполне может помочь. 1400 вполне норм будет.

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

в основном офисе на шлюзе стоит multi-wan: проводной интернет(pppoe через ethernet) и Yota-модем в usb, на обоих static ip,в удаленном Yota-модем в роутер, а дальше в шлюз с OpenVPN. При подключении на ip проводного инета, он подключается, но рандомно падает с приведенным выше логом, может минут на 20,может меньше.И при этом как то заметил пару ошибок с упоминанием mtu=1400 код 90. Как я выяснил у проводного провайдера mtu=1500, а у Yota mtu=1400.

можешь помочь с мту? я так понимаю указание в обоих конфигах mtu-tun=1400 недостаточно,там есть же еще всякие mtu extra,mssfix

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

у меня на yota была такая же проблема, решение не нашел, благо yota была заменена на нормальный интернет

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

напомни, если не лень, как работает опенвпн с

proto tcp

может я чего то не понимаю

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

Дык все просто. В конфиге как сервера, так и клиента. Последняя строка нужна только если клиент - винда.

tun-mtu 1400
tun-mtu-extra 32
mssfix

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

Хорошо, значит я не правильно понял ваш третий комментарий.

Ещё можно попробовать icmp-пакеты больших размеров не через vpn-тунель, а напрямую (″ping -s 2000″) и больше (10000-30000). Если YOTA не режет icmp, то ping с размером больше MTU физического линка приводит к появлению нескольких фрагментов (пакетов) идущих по линии подряд. Это хорошая проверка качества линии и, возможно, что вы просто хотите от YOTA невозможного.

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

Вообщем, клиент под виндой в основном офисе подключаясь к серверу OpenVPN по локальной сети работает отлично!

Ради интереса упростил конфиги до:

remote 80.240.60.64 1194
dev tun
proto udp
ifconfig 10.8.0.2 10.8.0.1
secret static.key
keepalive 10 120
persist-key
persist-tun
comp-lzo
verb 3
чтобы исключить TLS

лог на клиенте стал выглядеть так:

Mar 27 17:53:41 vpn openvpn[10517]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-$
Mar 27 17:53:41 vpn openvpn[10517]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 27 17:53:41 vpn openvpn[10517]: Re-using pre-shared static key
Mar 27 17:53:41 vpn openvpn[10517]: LZO compression initialized
Mar 27 17:53:41 vpn openvpn[10517]: Socket Buffers: R=[196608->131072] S=[196608->131072]
Mar 27 17:53:41 vpn openvpn[10517]: Preserving previous TUN/TAP instance: tun0
Mar 27 17:53:41 vpn openvpn[10517]: Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Mar 27 17:53:41 vpn openvpn[10517]: Local Options hash (VER=V4): '48593abd'
Mar 27 17:53:41 vpn openvpn[10517]: Expected Remote Options hash (VER=V4): '4b91e501'
Mar 27 17:53:41 vpn openvpn[10517]: UDPv4 link local (bound): [undef]:1194
Mar 27 17:53:41 vpn openvpn[10517]: UDPv4 link remote: 80.240.60.64:1194
Mar 27 17:53:49 vpn openvpn[10517]: Peer Connection Initiated with 80.240.60.64:1194
Mar 27 17:53:49 vpn openvpn[10517]: Initialization Sequence Completed
Mar 27 18:35:32 vpn openvpn[10517]: Inactivity timeout (--ping-restart), restarting
Mar 27 18:35:32 vpn openvpn[10517]: TCP/UDP: Closing socket
Mar 27 18:35:32 vpn openvpn[10517]: SIGUSR1[soft,ping-restart] received, process restarting
Mar 27 18:35:32 vpn openvpn[10517]: Restart pause, 2 second(s)
Mar 27 18:35:34 vpn openvpn[10517]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-$
Mar 27 18:35:34 vpn openvpn[10517]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 27 18:35:34 vpn openvpn[10517]: Re-using pre-shared static key
Mar 27 18:35:34 vpn openvpn[10517]: LZO compression initialized
Mar 27 18:35:34 vpn openvpn[10517]: Socket Buffers: R=[196608->131072] S=[196608->131072]
Mar 27 18:35:34 vpn openvpn[10517]: Preserving previous TUN/TAP instance: tun0
Mar 27 18:35:34 vpn openvpn[10517]: Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Mar 27 18:35:34 vpn openvpn[10517]: Local Options hash (VER=V4): '48593abd'
Mar 27 18:35:34 vpn openvpn[10517]: Expected Remote Options hash (VER=V4): '4b91e501'
Mar 27 18:35:34 vpn openvpn[10517]: UDPv4 link local (bound): [undef]:1194
Mar 27 18:35:34 vpn openvpn[10517]: UDPv4 link remote: 80.240.60.64:1194
Mar 27 18:37:34 vpn openvpn[10517]: Inactivity timeout (--ping-restart), restarting
Mar 27 18:37:34 vpn openvpn[10517]: TCP/UDP: Closing socket
Mar 27 18:37:34 vpn openvpn[10517]: SIGUSR1[soft,ping-restart] received, process restarting
Mar 27 18:37:34 vpn openvpn[10517]: Restart pause, 2 second(s)

Я так понимаю,что проблема в потерях пакетов. С этим можно как нибудь бороться?Может какой нить PPTP или IPSec поднять, поможет ли?Или что посоветуете для объединения сетей двух офисов и SIP между ними?

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

Проблемы с потерей пакетов диагностируются с помощью утилит ping, iperf. Можно с помощью nc и tcpdump. openvpn не относится к утилитам диагностики канала.

С этим можно как нибудь бороться?

Иногда на радиоканалах помогает небольшое значение в ″link-mtu″.

PPtP ещё более критичен к потери пакетов, чем openvpn.

Если у вас на физическом уровне заметные потери пакетов, то никакие тунели не спасут, особенно для SIP-трафика.

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

Проблемы с потерей пакетов диагностируются с помощью утилит ping, iperf. Можно с помощью nc и tcpdump. openvpn не относится к утилитам диагностики канала.

это понятное дело, сейчас iperf запустил, выложу лог.

Иногда на радиоканалах помогает небольшое значение в ″link-mtu″.

а что означает link-mtu?

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

лог с сервера:

Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  224 KByte (default)

[  5] local XX.XX.XX.XX port 5001 connected with YY.YY.YY.YY port 62969
[  5]  0.0-1317.2 sec  37.5 MBytes   239 Kbits/sec   3.519 ms   33/26751 (0.12%)
[  5]  0.0-1317.2 sec  706 datagrams received out-of-order

Лог клиента:

iperf -u -c 80.240.60.64 -t 300

Client connecting to XX.XX.XX.XX.XX, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  192 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.254 port 48402 connected with XX.XX.XX.XX port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-300.0 sec  37.5 MBytes  1.05 Mbits/sec
[  3] Sent 26751 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

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

По этому логу у вас нормальный канал.

Но, нужно добавить серверу опцию ″-i 10″ и перенаправить вывод в файл, чтобы потом можно было оценить, «размазаны» ли потери пакетов равномерно, или есть интервалы времени, когда вобще пакеты не проходят. Тесты сделать в оба направления (можно одновременно на разных портах на каждой машине запустить и сервер и клиент).

Если у вас безлимитный трафик, то надо сделать тест делать минут 20-30, раз у вас разрывы связи были где-то через 20 мин.

Все результаты тестов сюда выкладывать не надо, это ваш канал, вам понимать, можно ли на нём работать.

Можно поделать тесты в разное время суток, попробовать одновременно с тестированием загрузить канал другим трафиком (допустим http) и посмотреть, что влияет на потери udp-пакетов.

P.S. link-mtu это ограничение размера udp-пакета, несущего openvpn данные. Чем он меньше, тем, ИМХО, на радиоканале больше шансов, что он дойдёт.

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

в общем переключил на TCP протокол и все заработало. компы по ip адресам открываются из обоих сетей,SIP проходит нормально. Единственный вопрос: в основном офисе есть AD на Win Serv 2008, а вот во удаленном офисе компы не видят его как сервер AD, хотя по IP он открывается, можно с этим чтонить придумать?

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

По поводу AD. У вас должны быть DNS-записи типа SRV, указывающие на этот ваш Win Serv 2008. Вот базовые записи: http://searchwindowsserver.techtarget.com/tip/Basic-DNS-records-for-Active-Di...

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

Если вы про ″TLS: soft reset″, то это просто генерация нового ключа и траффик в этот момент должен продолжать ходить. Но можно поднять это, задав в обоих конфигах (клиента и сервера) опцию ″reneg-sec″. Не знаю правда, насколько это безопасно, по идее, чем больше данных шифровано одним ключём, тем легче третей стороне, перехватывающей эти данные, расшифровать их.

mky ★★★★★ ()

попробуйте добавить в конфиги tls-auth и соответственно сгенерированный ключ под параметр

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