Como descobrir o que está bloqueando meu tráfego OpenVPN

0

Estou tendo um problema para fazer com que minha rota push do OpenVPN funcione.

Minha configuração é a seguinte

Rede

  • Homelan: 10.0.0.0/24 com
  • OpenVPN: 10.8.0.0/24
  • VPS na Internet

Servidores (todos Linux)

  • Servidor1: 10.0.0.13 + 10.8.0.1 (o servidor OpenVPN)
  • Servidor 2: 10.0.0.11 (DHCP + DNS)
  • VPS: Internet IP + 10.8.0.X (IP aleatório do OpenVPN)

Configuração do OpenVPN Server

..snip..
push "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.11"
..snip..

IP ativo ativado

cat /proc/sys/net/ipv4/ip_forward
1

Route VPS

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         www.xxx.yyy.1    0.0.0.0         UG    0      0        0 eth0
10.0.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
www.xxx.yyy.1    *               255.255.255.255 UH    0      0        0 eth0

Route Server1

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        *               255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0

Tente fazer ping no servidor openvpn (10.8.0.1) do VPS

ping 10.0.0.13
ping 10.0.0.13 -I tun0;#gives same result

tcpdump do VPS

tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
19:05:22.049141 IP 10.8.0.6 > 10.8.0.1: ICMP echo request, id 17966, seq 1, length 64
19:05:22.101397 IP 10.8.0.1 > 10.8.0.6: ICMP echo reply, id 17966, seq 1, length 64

tcpdump server1

tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
18:05:22.064139 IP 10.8.0.6 > 10.8.0.1: ICMP echo request, id 17966, seq 1, length 64
18:05:22.064399 IP 10.8.0.1 > 10.8.0.6: ICMP echo reply, id 17966, seq 1, length 64
18:05:23.065687 IP 10.8.0.6 > 10.8.0.1: ICMP echo request, id 17966, seq 2, length 64
18:05:23.065886 IP 10.8.0.1 > 10.8.0.6: ICMP echo reply, id 17966, seq 2, length 64

O que não está funcionando é a conexão do VPS ao IP interno do Servidor 1

Tente fazer ping no servidor openvpn (10.0.0.13) do VPS

tcpdump do VPS

19:12:24.847216 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 1, length 64 
19:12:25.876441 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 2, length 64 
19:12:26.900408 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 3, length 64 
19:12:27.924476 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 4, length 64 
19:12:39.964724 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18137, seq 1, length 64 
19:12:40.980446 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18137, seq 2, length 64 

tcpdump do Server1

#stays empty

Então estou realmente me perguntando o que está errado aqui. Qual seria o próximo passo para descobrir o que está bloqueando meu tráfego do VPS para os IPs internos de 10.0.0.0/24? Talvez um firewall no homelan esteja bloqueando o tráfego? Como descobrir?

    
por syss 10.02.2018 / 19:23

1 resposta

0

Alcançando interface interna, sem roteamento
Por padrão, o Linux responderá a qualquer um de seus IPs em qualquer interface, ele responderá até mesmo a solicitações ARP na interface "errada". Isso é super inseguro, então a maioria dos firewalls bloqueará esse comportamento usando iptables e proc / arp_filter.

Você pode ter regras de firewall que bloqueiam o roteamento em: server1> iptables -L -n -v server1> iptables -t nat -L -n -v

server1> iptables -A FORWARD -j LOG irá registrar (dmesg) todos os pacotes roteados entre 10.8 e 10.0 pelo servidor1. Pode dar alguma informação. $server1> iptables -D FORWARD -j LOG para remover a regra.

A seguir, serão inseridas regras de roteamento antes de qualquer regra de firewall.
server1> echo 1 > /proc/sys/net/ipv4/ip_forward
server1> iptables -I FORWARD 1 --in-interface tun0 --source 10.8.0.0/24 -j ACCEPT
server1> iptables -I FORWARD 1 --in-interface eth0 --source 10.0.0.0/24 -j ACCEPT

Eu não esperaria que VPS> ping 10.0.0.11 funcionasse, mas se isso ocorrer, o problema é quase certamente no iptables do servidor1.

Você está roteando através de server1 em um ponto a ponto, então ele não deveria estar fazendo ARP, mas se qualquer um deles estiver configurado para 1, provavelmente foi feito por um script de firewall e o problema estará no iptables do servidor1. br> server1> cat /proc/sys/net/ipv4/conf/all/arp_filter e server1> cat /proc/sys/net/ipv4/conf/tun0/arp_filter

Rotas em Suas rotas parecem boas, mas com essa configuração você não precisa dos 10.8.0.0/24 que estão lá. 10.8.0.1 a 10.8.0.5 é ponto-a-ponto.

O VPS deve ter default gw , 10.8.0.1 via tun0 e 10.0.0.0/24 via gw 10.8.0.1 .
server1 deve ter default gw e 10.8.0.5 via tun0 e 10.0.0.0/24 via eth0 .

    
por 11.02.2018 / 21:02