Pings da rede VPN para o trabalho do cliente VPN; pings de cliente VPN para falha de rede VPN - por quê?

Question

Pings da rede VPN para o trabalho do cliente VPN; pings de cliente VPN para falha de rede VPN - por quê?

#1 resposta do (4 votos)
#2 resposta do (3 votos)

5

Estamos no processo de configurar um servidor OpenVPN para alguns servidores em execução em nuvem. Estamos perplexos com um problema de conectividade pelo qual os hosts na LAN do servidor VPN podem executar ping no cliente VPN, mas o inverso não é verdadeiro.

O cliente VPN pode executar ping no servidor VPN em seu endereço de VPN, mas não em seu endereço de LAN.

O tcpdump mostra a evidência de pacotes de ping do cliente que chega ao host e as respostas são emitidas, mas por algum motivo as respostas nunca alcançam a interface tun0 no servidor VPN ou no cliente. Por outro lado, o tráfego para as solicitações de ping da LAN do servidor VPN para o cliente VPN é visto em todas as interfaces esperadas, de acordo com o tcpdump.

Uma descrição detalhada de nossa configuração e solução de problemas até o momento é fornecida abaixo.

O problema parece estar relacionado ao encaminhamento de endereços na rede do servidor para a rede do cliente. O que é realmente estranho (para mim) é que os pings iniciados pela LAN podem fazer a ida e volta completa, mas os pings iniciados pelo cliente parecem ter caído em algum lugar entre as interfaces tun0 e eth1 do servidor VPN.

O que estamos perdendo?

Situação:

3 hosts:

Cliente VPN (tun0: 10.8.0.22)
servidor VPN (tun0: 10.8.0.1, eth1: 10.11.11.2, eth0: x.x.x.x)
servidor da LAN (eth0: 10.11.11.7)

Ambos os servidores são máquinas virtuais, executando o RHEL 5.7. Eu acho (mas não tenho certeza) que o ambiente de hospedagem virtual é o VMWare.

Testes

O cliente VPN estabeleceu o túnel para o servidor VPN, por meio da interface eth0 do servidor VPN
O cliente VPN pode executar ping no servidor VPN em sua interface tun0 10.8.0.1
O servidor VPN pode fazer ping 10.8.0.22
O servidor da LAN pode fazer ping 10.8.0.22

mas:

O cliente VPN não pode executar o ping VPN server em sua interface eth1 10.11.11.2
O cliente VPN não pode fazer o ping no servidor da LAN na sua interface eth0 10.11.11.7

Para o teste de ping entre 10.11.11.7 e 10.8.0.22:

O tcpdump mostra solicitações e respostas de ping que atravessam o tun0 no servidor VPN
O tcpdump mostra solicitações e respostas de ping percorrendo a eth1 no servidor VPN
O tcpdump mostra solicitações e respostas de ping atravessando a eth0 no servidor de rede local

Para o teste de ping entre 10.11.11.2 e 10.8.0.22:

O tcpdump mostra solicitações e respostas de ping que atravessam o tun0 no servidor VPN

Para o teste de ping entre 10.8.0.22 e 10.11.11.2:

O tcpdump mostra os pedidos de ping que atravessam o tun0 no servidor VPN
O tcpdump mostra respostas de ping percorrendo a eth1 no servidor VPN
não há nenhum vestígio da resposta na interface tun0

Para o teste de ping entre 10.8.0.22 e 10.11.11.7:

O tcpdump mostra os pedidos de ping que atravessam o tun0 no servidor VPN
O tcpdump mostra solicitações de ping que atravessam a eth1 no servidor VPN
O tcpdump mostra os pedidos de ping que atravessam a eth0 no servidor da LAN
O tcpdump mostra respostas de ping atravessando a eth0 no servidor de rede local
não há nenhum vestígio da resposta nas interfaces tun0 ou eth1 do servidor VPN

ip_fowarding foi ativado no servidor VPN O rp_filter foi desativado no servidor VPN para todas as interfaces, exceto a interface voltada para a Internet, eth0.

O iptables foi desabilitado com regras (padrão ACCEPT) no cliente para fins de depuração do problema subjacente.

Incluímos dumps da rota -n e ifconfig para as interfaces relevantes em cada host.

No servidor OpenVPN

$ /sbin/route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
x.x.x.x     0.0.0.0         255.255.248.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         x.x.x.x     0.0.0.0         UG    0      0        0 eth0

$ find /proc/sys/net -name 'rp_filter' | while read f
> do echo $f $(cat $f)
> done
/proc/sys/net/ipv4/conf/tun0/rp_filter 0
/proc/sys/net/ipv4/conf/eth1/rp_filter 0
/proc/sys/net/ipv4/conf/eth0/rp_filter 1
/proc/sys/net/ipv4/conf/lo/rp_filter 0
/proc/sys/net/ipv4/conf/default/rp_filter 0
/proc/sys/net/ipv4/conf/all/rp_filter 0

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

$ sudo /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   


$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr DE:AD:BE:A6:28:21  
          inet addr:x.x.x.x  Bcast:x.x.x.x  Mask:255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:233929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24776 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:27881415 (26.5 MiB)  TX bytes:30534780 (29.1 MiB)

eth1      Link encap:Ethernet  HWaddr DE:AD:BE:3B:24:48  
          inet addr:10.11.11.2  Bcast:10.11.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4929 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:423658 (413.7 KiB)  TX bytes:863546 (843.3 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11992 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:34820967 (33.2 MiB)  TX bytes:34820967 (33.2 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:69 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:5796 (5.6 KiB)  TX bytes:4788 (4.6 KiB)

$ uname -a
Linux vhost0273 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

$ ping -c1 10.8.0.22 -w 1
PING 10.8.0.22 (10.8.0.22) 56(84) bytes of data.
64 bytes from 10.8.0.22: icmp_seq=1 ttl=64 time=145 ms

--- 10.8.0.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 145.676/145.676/145.676/0.000 ms

$ ping -c1 10.11.11.7 -w 1
PING 10.11.11.7 (10.11.11.7) 56(84) bytes of data.
64 bytes from 10.11.11.7: icmp_seq=1 ttl=64 time=0.794 ms

--- 10.11.11.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.794/0.794/0.794/0.000 ms

Em um host na LAN do servidor:

$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr DE:AD:BE:7F:45:72  
          inet addr:10.11.11.7  Bcast:10.11.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33897 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2536157 (2.4 MiB)  TX bytes:8910725 (8.4 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:77779 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77779 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.11.11.2      255.255.255.0   UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.11.11.2      0.0.0.0         UG    0      0        0 eth0

$ ping -c1 10.8.0.1 -w 1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.516 ms

--- 10.8.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.516/0.516/0.516/0.000 ms

$ ping -c1 10.8.0.22 -w 1
PING 10.8.0.22 (10.8.0.22) 56(84) bytes of data.
64 bytes from 10.8.0.22: icmp_seq=1 ttl=63 time=146 ms

--- 10.8.0.22 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 146.913/146.913/146.913/0.000 ms

$ ping -c1 10.11.11.2 -w 1
PING 10.11.11.2 (10.11.11.2) 56(84) bytes of data.
64 bytes from 10.11.11.2: icmp_seq=1 ttl=64 time=0.775 ms

--- 10.11.11.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.775/0.775/0.775/0.000 ms

No cliente VPN

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.22  P-t-P:10.8.0.21  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:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

$ /sbin/route -n | grep ^10
10.8.0.21       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.0.1.0        0.0.0.0         255.255.255.0   U     2      0        0 wlan0
10.1.1.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.11.11.0      10.8.0.1        255.255.255.0   UG    0      0        0 tun0

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=145 ms

$ ping 10.8.0.2 -w 1
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.

--- 10.8.0.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.11.11.2 -w 1
PING 10.11.11.2 (10.11.11.2) 56(84) bytes of data.

--- 10.11.11.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.11.11.7 -w 1
PING 10.11.11.7 (10.11.11.7) 56(84) bytes of data.

--- 10.11.11.7 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

openvpn ping tcpdump ip-forwarding

por jonseymour 14.03.2012 / 00:24

2 respostas

3

E as regras do iptables? Eles parecem bastante vazios.

Eu uso as seguintes regras, mas não tenho certeza se isso resolveria seu problema exato:

# Allow TUN interface connections to OpenVPN server
iptables -A INPUT -i tun+ -j ACCEPT

# Allow TUN interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -o tun+ -j ACCEPT

# Allow TUN interface connections to get out
iptables -A OUTPUT -o tun+ -j ACCEPT

# We want to allow routing from OpenVPN tunnels
$IPTABLES -t nat -A POSTROUTING -o eth1 -s 10.8.1.0/255.255.255.0 -j MASQUERADE
$IPTABLES -A FORWARD -i tun+ -o eth1 -s 10.8.1.0/255.255.255.0 -j ACCEPT

No gateway, você precisa de uma entrada de roteamento para direcionar o tráfego para 10.8.1.0/24 para o servidor openvpn.

No tráfego do servidor openvpn para a sub-rede 10.8.1.0/24, o endereço IP da interface tun do servidor openvpn, por exemplo, 10.8.1.2. Isso ainda deve ser configurado pelo próprio openvpn.

Atualização: Eu tive que editar algumas coisas, eu uso uma configuração aqui com 2 servidores openvpn que também se comunicam uns com os outros. Então eu misturei algumas coisas que não são relevantes para sua situação.

por 14.03.2012 / 01:09

Tags openvpn ping tcpdump ip-forwarding

Quais são alguns sistemas de arquivos compartilhados que as pessoas usaram com sucesso com o iSCSI? O que significa “acl cdn_name hdr_beg (host) -i foor.bar.com” na configuração do HAProxy?

score 4 · Accepted Answer

A causa deste problema foram algumas rotas implícitas padrão que não eram visíveis nas tabelas exibidas por / sbin / route, mas que eram visíveis nas tabelas mostradas pela regra / sbin / ip e / sbin / ip.

Em seguida, essas tabelas foram exibidas tornou-se aparente que uma regra deste tipo:

default table route_eth0 via 10.11.11.1  dev eth0

estava substituindo esta regra:

10.8.0.0        10.11.11.2      255.255.255.0   UG    0      0        0 eth0

Ao editar o / etc / sysconfig / network-scripts / route-eth0 (provavelmente com o / sbin / ip route, embora manualmente, neste caso), eu pude corrigir o problema.

Então, o que eu aprendi com isso é que / sbin / route não pode ser usado para fornecer uma imagem precisa das regras de roteamento efetivas do Linux e que é melhor usar o / sbin / ip para esse propósito.

Obrigado ao ptman cuja resposta para este pergunta me ajudou a ver a luz. Obrigado ptman!