Servidor OpenVPN, porta UDP não mais acessível

Question

Estou tendo um problema estranho com o OpenVPN. O servidor funcionou bem e sem modificação por um longo tempo, exceto para atualizações. De repente parou de funcionar e não consigo descobrir o porquê. Não consigo acessar sua porta UDP remotamente, a partir da domU ou da máquina local. Eu posso alcançar todos os outros serviços.

Eu tentei desativar o iptables como um experimento, mas ainda não consigo acessar a porta. Não consigo ver nada de errado na configuração do OpenVPN. A execução de netstat -lp | grep openvpn revela que a porta está escutando. Ainda não consigo acessá-lo da máquina local.

Aqui está a configuração do OpenVPN: link

Aqui está a saída do link iptables -nvL :

Aqui está a saída do link iptables -nvL -t nat :

Eu acho que eliminei todos os outros fatores que poderiam ser. Por favor me ajude a diagnosticar esta questão ainda mais.

Este é o log do serviço começando ...

Tue Apr 28 07:04:39 2015 us=123021 OpenVPN 2.3.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Apr 27 2015
Tue Apr 28 07:04:39 2015 us=123031 library versions: OpenSSL 1.0.1l 15 Jan 2015, LZO 2.08
Tue Apr 28 07:04:39 2015 us=127292 Diffie-Hellman initialized with 2048 bit key
Enter Private Key Password:
Tue Apr 28 07:04:47 2015 us=695418 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Apr 28 07:04:47 2015 us=698002 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Apr 28 07:04:47 2015 us=698025 Socket Buffers: R=[212992->131072] S=[212992->131072]
Tue Apr 28 07:04:47 2015 us=698114 ROUTE_GATEWAY 167.114.15.64/255.255.255.0 IFACE=eth0 HWADDR=ba:e5:54:4f:ef:d7
Tue Apr 28 07:04:47 2015 us=698259 TUN/TAP device tun0 opened
Tue Apr 28 07:04:47 2015 us=698294 TUN/TAP TX queue length set to 100
Tue Apr 28 07:04:47 2015 us=698317 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Apr 28 07:04:47 2015 us=698340 /bin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Tue Apr 28 07:04:47 2015 us=699313 /bin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Tue Apr 28 07:04:47 2015 us=699853 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Apr 28 07:04:47 2015 us=700326 GID set to openvpn
Tue Apr 28 07:04:47 2015 us=700368 UID set to openvpn
Tue Apr 28 07:04:47 2015 us=700394 UDPv4 link local (bound): [AF_INET]167.114.15.70:1194
Tue Apr 28 07:04:47 2015 us=700407 UDPv4 link remote: [undef]
Tue Apr 28 07:04:47 2015 us=700422 MULTI: multi_init called, r=256 v=256
Tue Apr 28 07:04:47 2015 us=700460 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Tue Apr 28 07:04:47 2015 us=700480 ifconfig_pool_read(), in='client-johntate,10.8.0.4', TODO: IPv6
Tue Apr 28 07:04:47 2015 us=700498 succeeded -> ifconfig_pool_set()
Tue Apr 28 07:04:47 2015 us=700511 ifconfig_pool_read(), in='client-lucasmarshall2,10.8.0.8', TODO: IPv6
Tue Apr 28 07:04:47 2015 us=700521 succeeded -> ifconfig_pool_set()
Tue Apr 28 07:04:47 2015 us=700531 ifconfig_pool_read(), in='client-testuser4,10.8.0.12', TODO: IPv6
Tue Apr 28 07:04:47 2015 us=700543 succeeded -> ifconfig_pool_set()
Tue Apr 28 07:04:47 2015 us=700556 IFCONFIG POOL LIST
Tue Apr 28 07:04:47 2015 us=700570 client-obfuscated1,10.8.0.4
Tue Apr 28 07:04:47 2015 us=700582 client-obfuscated2,10.8.0.8
Tue Apr 28 07:04:47 2015 us=700593 client-obfuscated3,10.8.0.12
Tue Apr 28 07:04:47 2015 us=700632 Initialization Sequence Completed

Edit: Eu fiz mais um teste e parece que o sistema não pode escutar o UDP. Mesmo com o firewall desativado. Isso não faz sentido algum. Para testar, usei socat para ouvir UDP e hping para testá-lo.

    

Answer 1

É o VPS (OVH) @ Canada? Se sim, então você deve entrar em contato com o seu suporte. Sua configuração parece perfeitamente normal para mim. De acordo com o contador iptables, o kernel do sistema operacional não recebe nada na porta do @ openvpn (1194 / UDP). Cheira a problemas de conexão para mim. É por isso que o openvpn não funciona. Você não pode diagnosticar, apenas o seu provedor pode. Eles geralmente usam uma configuração complexa para minimizar os custos e fornecer a melhor distribuição de endereços IP públicos. É muito fácil cometer algum erro aí.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
15 3291 ACCEPT all -- * * 10.8.0.0/24 0.0.0.0/0
217M 74G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 3155K 189M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
53874 3814K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 357K 12M ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 ctstate NEW 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 305K 68M UDP udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW 3802K 204M TCP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 ctstate NEW 290K 67M REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 125K 6870K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable 0 0 sshguard all -- * * 0.0.0.0/0 0.0.0.0/0

Você pode fornecer também ifconfig -a output? Você também pode ver a saída tcpdump / wireshark. Deve provar o que eu digo. Você pode tentar encontrar a porta udp disponível abaixo:

@ server

tshark -i ethX udp or tshark -i ethX -f 'udp' depending on version

@ some client

nmap -sU server's_IP_address -p 1-65535

E observe o output @ server. Isso deve dizer a você quais portas UDP estão abertas. Para testar o OpenVPN, você pode alternar para o TCP, eliminará problemas de configuração do OpenVPN e fornecerá conectividade de backup por enquanto.

E boa sorte!