openvpn O handshake de TLS falha no cliente porque o firewall descarta pacotes (mas por quê?)

4

Eu pareço ter problema com o meu servidor openvpn - conexão com o cliente.

agora, as informações importantes estão no log (verb3) do meu cliente:

Mon Mar 30 17:09:59 2015 OpenVPN 2.2.2 x86_64-slackware-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Jul  4 2012
Mon Mar 30 17:09:59 2015 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Mar 30 17:09:59 2015 LZO compression initialized
Mon Mar 30 17:09:59 2015 Control Channel MTU parms [ L:1546 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Mar 30 17:09:59 2015 Socket Buffers: R=[229376->131072] S=[229376->131072]
Mon Mar 30 17:10:00 2015 Data Channel MTU parms [ L:1546 D:1300 EF:46 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Mar 30 17:10:00 2015 Fragmentation MTU parms [ L:1546 D:1300 EF:45 EB:135 ET:1 EL:0 AF:3/1 ]
Mon Mar 30 17:10:00 2015 Local Options hash (VER=V4): 'c086e1aa'
Mon Mar 30 17:10:00 2015 Expected Remote Options hash (VER=V4): '8e7959c7'
Mon Mar 30 17:10:00 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mon Mar 30 17:10:00 2015 UDPv4 link local: [undef]
Mon Mar 30 17:10:00 2015 UDPv4 link remote: x.x.x.x:32386

Aqui é onde fica preso. Observe que x.x.x.x s o endereço IP do meu servidor e a porta de escuta openvpn é 32386. depois de um tempo isso aparece

Mon Mar 30 17:12:04 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 30 17:12:04 2015 TLS Error: TLS handshake failed
Mon Mar 30 17:12:04 2015 TCP/UDP: Closing socket
Mon Mar 30 17:12:04 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Mar 30 17:12:04 2015 Restart pause, 2 second(s)

Se eu desabilitar o firewall do meu cliente e eu reiniciar o cliente openvpn, ele se conectará bem.

Então o problema está relacionado ao firewall. Eu configurei um tcpdump -i <external_if> host <public_ip_of_the_other_pc> para ouvir pacotes entre os dois computadores.

os 2 últimos pacotes que chegaram ao cliente:

18:58:14.193351 IP adsl-x.x.x.x.tellas.gr.26382 > 192.168.201.210.42983: UDP, length 14
18:58:14.796510 IP 192.168.201.210.42983 > adsl-x.x.x.x.tellas.gr.32386: UDP, length 14
18:58:14.821572 IP adsl-x.x.x.x.tellas.gr.26382 > 192.168.201.210.42983: UDP, length 22

observe que 192.168.201.210 é o ip do modem ADSL no cliente.

Ao mesmo tempo, o firewall soltou os pacotes que chegavam na porta 42983

Mar 30 18:57:44 halki INPUT packet died:  IN=eth1 OUT= MAC=00:11:6b:32:f7:7e:00:13:33:16:36:12:08:00  SRC=x.x.x.x DST=192.168.201.210 LEN=54 TOS=1C PREC=0x20 TTL=56 ID=0 DF PROTO=UDP SPT=26382 DPT=42983 LEN=34 
Mar 30 18:57:50 halki INPUT packet died:  IN=eth1 OUT= MAC=00:11:6b:32:f7:7e:00:13:33:16:36:12:08:00  SRC=x.x.x.x DST=192.168.201.210 LEN=50 TOS=1C PREC=0x20 TTL=56 ID=0 DF PROTO=UDP SPT=26382 DPT=42983 LEN=30 
Mar 30 18:58:14 halki INPUT packet died:  IN=eth1 OUT= MAC=00:11:6b:32:f7:7e:00:13:33:16:36:12:08:00  SRC=x.x.x.x DST=192.168.201.210 LEN=42 TOS=1C PREC=0x20 TTL=56 ID=0 DF PROTO=UDP SPT=26382 DPT=42983 LEN=22 

Obviamente, 42983 é uma porta alta que o cliente não precisa estar aberto. No entanto, como eu habilitei a inspeção de pacotes de estado no firewall do cliente, a porta 42983 deve estar acessível ao mundo externo, considerando que um momento atrás o cliente havia iniciado uma conexão com o servidor naquela porta de origem.

Para o registro da cadeia INPUT do firewall do meu cliente:

echo "Process INPUT chain ..."
$IPT -A INPUT -p ALL -i $LO_IFACE -j ACCEPT
$IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p ALL -i $LOCAL_IFACE -s $LOCAL_NET -j ACCEPT
$IPT -A INPUT -p TCP -i $INET_IFACE -j tcp_inbound
$IPT -A INPUT -p UDP -i $INET_IFACE -j udp_inbound
$IPT -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
$IPT -A INPUT -m pkttype --pkt-type broadcast -j DROP
$IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 -j ULOG --ulog-prefix "INPUT packet died: " --ulog-nlgroup 1

para que ESTABLISHED,RELATED conexões possam passar. Ou o que estou perdendo e o firewall não permite respostas do servidor openvpn para o cliente?

EDITAR:

$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 113 -j REJECT
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 137 -j DROP
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 138 -j DROP
$IPT -A udp_inbound -p UDP -s $MODEM --destination-port 123 -j ACCEPT #NTP
$IPT -A udp_inbound -p UDP -j RETURN

$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 113 -j REJECT
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 51235 -j ACCEPT #SSH
$IPT -A tcp_inbound -p TCP -j RETURN

$IPT -A icmp_packets --fragment -p ICMP -j ULOG --ulog-prefix "ICMP Fragment: " --ulog-nlgroup 1
$IPT -A icmp_packets --fragment -p ICMP -j DROP
$IPT -A icmp_packets -p ICMP -s $LOCAL_NET -d $VPN_NET --icmp-type 0 -j ACCEPT
$IPT -A icmp_packets -p ICMP -s $LOCAL_NET -d $VPNCL_NET --icmp-type 0 -j ACCEPT
$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
$IPT -A icmp_packets -p ICMP -j RETURN
    
por nass 30.03.2015 / 18:11

1 resposta

2

Como aconteceu, o problema não estava nas configurações de servidor ou cliente openvpn, mas sim no firmware do modem ADSL no lado do servidor.

O firmware tem um bug e alterou erroneamente a porta de origem de um pacote de saída. Então, enquanto o openvpn responderia na porta do servidor, o modem ADSL mudaria a porta de origem dos pacotes openvpn. O resultado foi que o cliente descartaria esses pacotes e a conexão openvpn não permaneceria "viva".

A alteração do firmware do modem ADSL resolveu esse problema.

    
por 07.12.2015 / 12:32