OPENVPN - Não funciona nem a pau

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 10:55h

Bom dia srs,
Preciso da ajuda útil de vossa senhoria, pessoal.

Configurar um OPENVPN é uma das coisas bem tranquilas que existem em questão de segurança e confiabilidade. Porém quando este serviço começa a dar pau e vc debuga, debuga e não consegue a solução. Pode ser algo bem pequeno que tenha passado batido que eu não esteja conseguindo enxergar.

Tinha uma VPN fechada com um cliente nosso, do qual funcionava tranquilamente com cada regrinha especifica. Porém o antigo analista que tomava conta da infra (que alias é gente boa pacas) zerou meu firewall com um flush. Dai começou a zica.

Enfim, minha VPN não trafega dados nem a pau e talvez seja algo bem pequeno que não esteja sabendo resolver.
Premissas:

LAN Interna: 172.16.0.0/16
VPN: 10.10.10.0/32

com o comando: openvpn --config /etc/openvpn ***.conf
não registra nenhuma falha.

No firewall liberei:

INPUT:
ACCEPT udp -- 200.*.*.* anywhere udp spt:5001

FORWARD:
ACCEPT udp -- 200.*.*.* anywhere udp dpt:5001

OUTPUT:
ACCEPT udp -- anywhere 200.*.*.* udp spt:openvpn
ACCEPT udp -- 200.*.*.* anywhere udp spt:5001


Adicionei também:

iptables -t nat -I POSTROUTING -s 10.10.10.0/32 -o eth0 -j MASQUERADE
iptables -t nat -I POSTROUTING -s 172.16.0.0/16 -o tun1 -j MASQUERADE

Alguém consegue me dizer se estou comendo bola em algo? Simplesmente não há tráfego:

inet addr:10.10.10.2 P-t-P:10.10.10.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:599 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:42440 (41.4 KiB)


Não penso que possa ser a chave da outra ponta, porém. Estou aberto a sugestões!

Desde já muito obrigado,

renato_pacheco
(usa Debian)

Enviado em 27/06/2012 - 11:01h

No servidor OpenVPN, olhe quais são as portas q ficam ativas quando a OpenVPN está conectada:

netstat -anutp

 

E veja quais portas ele abre pra se comunicar. Dae é só liberar no seu firewall.

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 11:31h

Veja só amigon,
Esqueci uma informação:
LAN_Interna_Cliente:
132.146.0.0/16


Dei um TS numa máquina destino (ponta VPN), o resultado com:

cat /proc/net/ip_conntrack | grep -a "172.16.4.24" | grep -a "132.146.160.25"

tcp 6 117 SYN_SENT src=172.16.4.24 dst=132.146.160.25 sport=51045 dport=3389 packets=2 bytes=104 [UNREPLIED] src=132.146.160.25 dst=10.10.10.2 sport=3389 dport=51045 packets=0 bytes=0 mark=0 secmark=0 use=2

Estanho que qdo volta, o dst é igual à : 10.10.10.2. O endereço do meu TUN1, isto esta certo?


O resultado no netstat foi identico com o opnevpn parado e no momento que iniciei o serviço:

tcp 0 52 172.16.2.1:ssh 172.16.4.24:49167 ESTABLISHED
tcp 0 0 172.16.2.1:ssh 172.16.4.24:50076 ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 9 [ ] DGRAM 3369 /dev/log
unix 2 [ ] DGRAM 1931 @/org/kernel/udev/udevd
unix 2 [ ] DGRAM 8827
unix 2 [ ] DGRAM 7499
unix 2 [ ] DGRAM 5470
unix 2 [ ] DGRAM 4698
unix 2 [ ] DGRAM 3646
unix 2 [ ] DGRAM 3596
unix 2 [ ] DGRAM 3420
unix 3 [ ] DGRAM 1936
unix 3 [ ] DGRAM 1935

Nda consta.

Alguma dica?
Obrigado.

renato_pacheco
(usa Debian)

Enviado em 27/06/2012 - 11:35h

Tente fazer um traceroute para o destino pra saber como está a rota. Talvez o problema esteja na própria rota.

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 12:18h

Esqueci que enviar as rotas, elas estão corretas porque as subo no momento de de inicializar o servico em
***.up, dentro de /etc/openvpn




177.23.222.2 189-*-*-*. 255.255.255.255 UGH 0 0 0 eth0
10.10.10.1 * 255.255.255.255 UH 0 0 0 tun1
200.*.*.* 189-*-*-*. 255.255.255.255 UGH 0 0 0 eth0
177.96.30.dynam 189-*-*-*. 255.255.255.255 UGH 0 0 0 eth0
187-54-5-233.ct 189-*-*-*. 255.255.255.255 UGH 0 0 0 eth0
189-*-*-*.0 * 255.255.255.0 U 0 0 0 eth0
186.220.96.0 * 255.255.240.0 U 0 0 0 eth1
132.146.0.0 10.10.10.1 255.255.0.0 UG 0 0 0 tun1
172.16.0.0 * 255.255.0.0 U 0 0 0 eth2


A terceira rota eu deixo apenas para que os usuários consigam se conectar ao cliente via VPN -ponto-a-ponto, fazendo assim um plano B.. para que não fiquem parados. Esta regra não influência porque teoricamente a rota que está no arquivo *.up é

/sbin/route add -net 132.146.0.0 netmask 255.255.0.0 gw 10.10.10.1

deve sobrepor quando peço requisições na rede interna do cliente...


Bom fiz um backup do firewall, e não aguentei e dei um -F...

Subi o serviço openvpn e fiz uma requisição, peguei as portas:

que houve "drop"

tcp 6 84 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50519 dport=9101 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=9101 dport=505s=0 bytes=0 mark=0 secmark=0 use=2
tcp 6 42 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50509 dport=9101 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=9101 dport=505s=0 bytes=0 mark=0 secmark=0 use=2
tcp 6 50 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50512 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50512 pbytes=0 mark=0 secmark=0 use=2
tcp 6 80 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50518 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50518 pbytes=0 mark=0 secmark=0 use=2
tcp 6 95 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50521 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50521 pbytes=0 mark=0 secmark=0 use=2
tcp 6 21 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50504 dport=9101 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=9101 dport=505s=0 bytes=0 mark=0 secmark=0 use=2
tcp 6 63 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50516 dport=9101 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=9101 dport=505s=0 bytes=0 mark=0 secmark=0 use=2
tcp 6 65 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50517 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50517 pbytes=0 mark=0 secmark=0 use=2
tcp 6 42 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50508 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50508 pbytes=0 mark=0 secmark=0 use=2
tcp 6 21 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50502 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50502 pbytes=0 mark=0 secmark=0 use=2
tcp 6 21 SYN_SENT src=172.16.4.25 dst=132.146.160.25 sport=50503 dport=80 packets=3 bytes=152 [UNREPLIED] src=132.146.160.25 dst=172.16.4.25 sport=80 dport=50503 pbytes=0 mark=0 secmark=0 use=2


vou libera-las e vamos ver o que vai dar. Porém alguma sugestão amigo?
Obrigado pela atenção...

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 12:35h

tail -n 10 /var/log/___.log

Wed Jun 27 11:58:04 2012 Local Options hash (VER=V4): '216375b8'
Wed Jun 27 11:58:04 2012 Expected Remote Options hash (VER=V4): 'cbd9413b'
Wed Jun 27 11:58:04 2012 GID set to root
Wed Jun 27 11:58:04 2012 UID set to root
Wed Jun 27 11:58:04 2012 UDPv4 link local (bound): [AF_INET]189.38.236.133:5001
Wed Jun 27 11:58:04 2012 UDPv4 link remote: [AF_INET]200.214.45.130:5001
Wed Jun 27 11:58:04 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
root@saopaulo:~# Wed Jun 27 11:58:04 2012 UDPv4 link remote: [AF_INET]200.*.*.*:5001

A conexão não é realizada na 5001.


pensando fiz:
iptables -A OUTPUT -s 172.16.0.0/16 -d 200.*.*.* -j ACCEPT

mas nada!

add também:
iptables -t nat -I POSTROUTING -s 172.16.0.0/16 -o tun1 -j MASQUERADE

Não sei mais o que fazer!!!!

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 12:44h

também add estas regras:

iptables -A OUTPUT -p udp --dport 5001 -j ACCEPT
iptables -A INPUT -p udp --dport 5001 -j ACCEPT
iptables -A FORWARD -p udp --dport 5001 -j ACCEPT

renato_pacheco
(usa Debian)

Enviado em 27/06/2012 - 13:42h

Se vc limpou as regras do seu firewall, se certifique q as políticas estejam como ACCEPT. O lance é fazer a OpenVPN funfar sem firewall. Depois vc coloca as regras aos poucos. Se não funcionar liberando geral, ae o problema pode ser no seu próprio OpenVPN.

Jogue aki o resultado dos comandos abaixo:

iptables -nL

iptables -t nat -nL

 

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 13:57h

# iptables -nL

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- 172.16.0.0/16 172.16.2.1 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
ACCEPT 47 -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 172.16.0.0/16 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 172.16.0.0/16 0.0.0.0/0 udp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5001
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12812

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 172.16.0.0/16 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 172.16.0.0/16 0.0.0.0/0 udp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5001
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12812

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 172.16.0.0/16 200.*.*.*
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5001
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12812



#iptables -t nat nL

Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.16.0.0/16 0.0.0.0/0
MASQUERADE all -- 172.16.0.0/16 !172.16.0.0/16
MASQUERADE all -- 172.16.0.0/16 !172.16.0.0/16

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


Uhm, Estão vazias as tabelas PREROUTING E OUTPUT. acho que o problem está aqui.... estou certo meu caro?

renato_pacheco
(usa Debian)

Enviado em 27/06/2012 - 14:02h

Pra gente t certeza d q não é o firewall, vamos limpar as regras:

iptables -F

iptables -t nat -F

 

Mudar a política padrão da cadeia INPUT:

iptables -P INPUT ACCEPT

 

E colocar o mascaramento para a sua rede:

iptables -t nat -A POSTROUTING -s 172.16.0.0/16 -j MASQUERADE

 

Agora faça os testes com a sua VPN e veja se conecta direitim. Caso positivo, vamos analisar com calma aonde q está o erro nessa suas regras.

allanv25
(usa Ubuntu)

Enviado em 27/06/2012 - 14:40h

Beleza, amigon..
Estou aguardando o momento certo para fazer isso na rede...hehe....one momento please!