Comportamento estranho de OpenVPN - desconecta após um minuto

Question

Comportamento estranho de OpenVPN - desconecta após um minuto

#1 resposta do (5 votos)
#2 resposta do (1 votos)
#3 resposta do (0 votos)

1

Estou usando o OpenVPN para conectar duas redes privadas e agora tenho um problema que não consigo resolver. Os servidores estão conectados com configuração UDP simples com chave estática. Eu já verifiquei iptables para limites ou algo assim e não há nada, também os dois servidores estão diretamente no IP público - não há roteadores / NAT ou algo entre eles. O servidor A está escutando e o servidor B é o cliente. Quando a VPN é iniciada, o cliente se conecta e tudo funciona perfeitamente, mas SOMENTE para o primeiro minuto. Então pare de funcionar. Conexão de túnel (ping de um ponto final para o outro) do servidor A para o servidor B ainda está funcionando (pode pingar), mas do outro lado, ele não funciona. Após o próximo watchdog de um minuto perceber, essa conexão está inativa no servidor B e reinicie o túnel. Então está funcionando por um minuto e isso se repete para sempre ...

Ambos os servidores são Ubuntu 64bits:

Servidor A:

root@server:/etc/openvpn# uname -an
Linux server 2.6.38-13-virtual #52~lucid1-Ubuntu SMP Thu Nov 10 19:46:44 UTC 2011 x86_64 GNU/Linux
root@server:/etc/openvpn# openvpn --version
OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 20 2010
Originally developed by James Yonan
Copyright (C) 2002-2009 OpenVPN Technologies, Inc.

Servidor B:

root@gw2:~# uname -an
Linux gw2 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
root@gw2:~# openvpn --version
OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 27 2013
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. 

  $ ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libexecdir=${prefix}/lib/openvpn --disable-maintainer-mode --disable-dependency-tracking CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now --enable-password-save --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=${prefix}/share/man --with-ifconfig-path=/sbin/ifconfig --with-route-path=/sbin/route

Compile time defines:  ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_EUREPHIA ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PASSWORD_SAVE ENABLE_PORT_SHARE ENABLE_SOCKS USE_CRYPTO USE_LIBDL USE_LZO USE_PF_INET6 USE_PKCS11 USE_SSL

Servidor Uma configuração ovpn:

daemon vpn-conn
writepid /var/run/openvpn-vpn.pid
dev tun3
proto udp
port 1859
comp-lzo
keepalive 10 30
persist-tun
persist-key
ifconfig 10.9.0.1 10.9.0.2
route 10.10.10.0 255.255.255.0
secret my-key.key
log-append vpn.log
verb 5

Servidor B:

daemon vpn
writepid /var/run/openvpn-vpn.pid
remote 4.3.2.1
dev tun0
proto udp
port 1859
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
ifconfig 10.9.0.2 10.9.0.1
route 192.168.0.0 255.255.252.0
secret my-key.key
log-append vpn.log
mtu-test
verb 5

Eu fiz algumas pesquisas para adicionar / remover "ping-timer-rem" "mtu-test" e "float" para configuração de cliente e servidor, mas o problema ainda permanece.

Servidor A ainda registrando coisas estranhas em log (eu acho, que pode ser a fonte do problema, mas eu não sei, como resolvê-lo. O tempo em ambos os servidores é o mesmo):

Wed Sep  4 10:25:44 2013 us=125832 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #100 / time = (1378283056) Wed Sep  4 10:24:16 2013 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Outro estranho no servidor A é que parece que o servidor B está se conectando a partir de dois soquetes! Eu verifiquei o servidor B e há apenas uma instância openvpn e nenhum outro. Quando eu mato, as sondas de conexão dos dois soquetes terminam.

Detalhes do log do servidor A:

Wed Sep  4 09:56:12 2013 us=544282 Peer Connection Initiated with [AF_INET]1.2.3.4:1859
Wed Sep  4 09:57:06 2013 us=661505 Peer Connection Initiated with [AF_INET]1.2.3.4:1194

Detalhe do servidor B:

Wed Sep  4 10:28:16 2013 us=98524 SIGUSR1[soft,ping-restart] received, process restarting
Wed Sep  4 10:28:16 2013 us=98562 Restart pause, 2 second(s)
Wed Sep  4 10:28:18 2013 us=98688 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Sep  4 10:28:18 2013 us=98871 Re-using pre-shared static key
Wed Sep  4 10:28:18 2013 us=98905 LZO compression initialized
Wed Sep  4 10:28:18 2013 us=98981 Socket Buffers: R=[229376->131072] S=[229376->131072]
Wed Sep  4 10:28:18 2013 us=99043 Preserving previous TUN/TAP instance: tun0
Wed Sep  4 10:28:18 2013 us=99075 Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Sep  4 10:28:18 2013 us=99144 Local Options String: 'V4,dev-type tun,link-mtu 1545,tun-mtu 1500,proto UDPv4,ifconfig 10.9.0.1 10.9.0.2,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,secret'
Wed Sep  4 10:28:18 2013 us=99167 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1545,tun-mtu 1500,proto UDPv4,ifconfig 10.9.0.2 10.9.0.1,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,secret'
Wed Sep  4 10:28:18 2013 us=99215 Local Options hash (VER=V4): '184f07f3'
Wed Sep  4 10:28:18 2013 us=99255 Expected Remote Options hash (VER=V4): 'de9a476a'
Wed Sep  4 10:28:18 2013 us=99291 UDPv4 link local (bound): [undef]
Wed Sep  4 10:28:18 2013 us=99321 UDPv4 link remote: [AF_INET]4.3.2.1:1859
WrWrWRWed Sep  4 10:28:21 2013 us=987011 Peer Connection Initiated with [AF_INET]4.3.2.1:1859
wrWrWed Sep  4 10:28:22 2013 us=847036 Initialization Sequence Completed
WrWRwrWRwrWWed Sep  4 10:28:24 2013 us=931728 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
WRwrWRRwrWRwrWrWWrWRwrWRWwrWRRwrWRWwrWRRwrWRwrWRWwrWRwrWRwrWRWwrWRRwrWRwrWRWwrWRwrWRwrWRWwrWRRwrWRwrWRWwrWRwrWRwWrWRRwrWRwrWRwrWRWwrWRwrWRwrWRWwrWRRwrWRWwrWRwrWRwrWRwrWRWwrWRRwrWRwrWRwrWRWwrWRwrWRWwrWRRwrWRwrWRWwrWRwrWRwrWRwrWrWWrWRRwrWR
wrWWRwrWRwrWRwrWrWrWRWwrWRWrWrWWrWWrWWWWWWWWWWWWWWWrWrWWWrWrWWed Sep  4 10:30:19 2013 us=505037 Inactivity timeout (--ping-restart), restarting
Wed Sep  4 10:30:19 2013 us=505153 TCP/UDP: Closing socket

No servidor B, NÃO há nenhuma string "1194" no log, mas quando tcpdump os pacotes entre os servidores (1.2.3.4 = cliente, 4.3.2.1 = servidor):

root@gw2:/etc/openvpn# tcpdump -ni eth0 host 4.3.2.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:34:43.534596 IP 4.3.2.1.1859 > 1.2.3.4.1859: UDP, length 100
10:34:43.535359 IP 1.2.3.4.1859 > 4.3.2.1.1859: UDP, length 100
10:34:44.468608 IP 4.3.2.1.1859 > 1.2.3.4.1859: UDP, length 100
10:34:44.481441 IP 1.2.3.4.1859 > 4.3.2.1.1859: UDP, length 100
10:34:45.476109 IP 4.3.2.1.1859 > 1.2.3.4.1859: UDP, length 100
10:34:45.476510 IP 1.2.3.4.1859 > 4.3.2.1.1859: UDP, length 60
10:34:45.477085 IP 1.2.3.4.1859 > 4.3.2.1.1859: UDP, length 100
HERE -->10:34:45.496917 IP 1.2.3.4.1194 > 4.3.2.1.1859: UDP, length 60
10:34:45.537356 IP 4.3.2.1.1859 > 1.2.3.4.1859: UDP, length 540
10:34:46.540260 IP 4.3.2.1.1859 > 1.2.3.4.1859: UDP, length 100
10:34:46.540955 IP 1.2.3.4.1859 > 4.3.2.1.1859: UDP, length 100
10:34:47.526090 IP 4.3.2.1.1859 > 1.2.3.4.1859: UDP, length 100
10:34:47.526793 IP 1.2.3.4.1859 > 4.3.2.1.1859: UDP, length 100

Parece que o cliente às vezes deseja se reconectar DO udp 1194 (em vez do 1859 correto) e a outra conexão, que já está em 1859, foi deixada em aberto. Portanto, o servidor A está enviando pacotes para a conexão 1859 (e pode pingar), mas o cliente muda o roteamento para o 1194, que não está inicializado e não está funcionando (e tenta se conectar a partir do soquete 1194 gera "erro de descriptografia" no servidor A ). Como eu disse - não há outra configuração nem instância de openvpn no cliente th (Servidor B) do que aquele que eu coloquei no topo.

Alguém poderia me dizer, o que poderia estar errado na minha configuração? Eu estou no fim da minha mente.

Obrigado.

J +

PS: Desculpe por mau inglês.

networking vpn openvpn linux ubuntu

por johnyq 04.09.2013 / 11:11

3 respostas

Tags networking vpn openvpn linux ubuntu

Qual é o propósito de /proc/config.gz Uma maneira prática de fazer a verificação de saúde de um novo servidor?

score 5 · Answer 1

Minha configuração não é exatamente a mesma descrita, mas os sintomas são os mesmos. O problema no meu caso foi tentar usar o mesmo certificado em dois computadores separados ao mesmo tempo. Ele alternou a conexão entre os dois computadores. Depois de criar um certificado separado, os dois computadores permaneceram na VPN solidamente.

score 1 · Answer 2

Tente remover a opção keepalive de um dos servidores. Esta opção se expande para isso

           if mode server:
             ping 10
             ping-restart 120
             push "ping 10"
             push "ping-restart 60"
           else
             ping 10
             ping-restart 60

Para sua configuração, mantenha a ramificação else, pois você não possui nenhum servidor no modo server . Portanto, seus servidores podem jogar pingue-pongue, pois existe a opção ping-restart definida em ambos os lados.

score 0 · Answer 3

Eu tive sintomas semelhantes. Meu problema foi resolvido alterando minha sub-rede local para 10.0.0.x, a partir de 192.168.1.x. A VPN do escritório que eu estava conectando também tinha a última sub-rede e estava em conflito.