Masquerade não está funcionando às vezes

Question

Masquerade não está funcionando às vezes

#1 resposta do (2 votos)

2

Eu tenho um problema com o tráfego da rede privada não ser mascarado em circunstâncias muito específicas.

A rede é um grupo de convidados VMware que usam a rede 10.1.0.0/18 .

O host problemático é 10.1.4.20 255.255.192.0 e o único gateway que ele está configurado para usar é 10.1.63.254 . O servidor de gateway $vpnGatewayAddress deve mascarar todo o tráfego de saída e encaminhá-lo por $outerGatewayAddress , mas por algum motivo, 10.1.4.20 acaba ocasionalmente com $outerGatewayAddress em seu cache de roteamento, como você pode ver aqui:

ip -s route show cache 199.16.156.40
199.16.156.40 from 10.1.4.20 via $outerGatewayAddress dev eth0
    cache  used 149 age 17sec ipid 0x9e49
199.16.156.40 via $outerGatewayAddress dev eth0  src 10.1.4.20
    cache  used 119 age 11sec ipid 0x9e49

O problema ocorre apenas com api.twitter.com

Depois de liberar o cache, posso fazer ping novamente e o cache parece correto:

ip route flush cache 199.16.156.40

ping api.twitter.com
PING api.twitter.com (199.16.156.40) 56(84) bytes of data.
64 bytes from 199.16.156.40: icmp_req=1 ttl=247 time=93.4 ms

ip -s route show cache 199.16.156.40
199.16.156.40 from 10.1.4.20 via 10.1.63.254 dev eth0
    cache  age 3sec
199.16.156.40 via 10.1.63.254 dev eth0  src 10.1.4.20
    cache  used 2 age 2sec

Informações de rede para o servidor de aplicativos (sem lo):

ip a

eth0      Link encap:Ethernet  HWaddr 00:50:56:a4:48:20
          inet addr:10.1.4.20  Bcast:10.1.63.255  Mask:255.255.192.0
          inet6 addr: fe80::250:56ff:fea4:4820/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1523222895 errors:0 dropped:407 overruns:0 frame:0
          TX packets:1444207934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1524116772058 (1.5 TB)  TX bytes:565691877505 (565.6 GB)

Informações de rede para o gateway da VPN (sem lo também):

 eth0      Link encap:Ethernet  HWaddr 00:50:56:a4:56:e9
           inet addr:$vpnGatewayAddress  Bcast:$broadcastAddress  Mask:255.255.255.192
           inet6 addr: fe80::250:56ff:fea4:56e9/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:7030472688 errors:0 dropped:1802 overruns:0 frame:0
           TX packets:6959026084 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:7777330931859 (7.7 TB)  TX bytes:7482143729162 (7.4 TB)

 eth0:0    Link encap:Ethernet  HWaddr 00:50:56:a4:56:e9
           inet addr:10.1.63.254  Bcast:10.1.63.255  Mask:255.255.192.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

 eth0:1    Link encap:Ethernet  HWaddr 00:50:56:a4:56:e9
           inet addr:10.1.127.254  Bcast:10.1.127.255  Mask:255.255.192.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

 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.1.1  P-t-P:10.8.1.2  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
           RX packets:477047415 errors:0 dropped:0 overruns:0 frame:0
           TX packets:833650386 errors:0 dropped:101834 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:89948688258 (89.9 GB)  TX bytes:1050533566879 (1.0 TB)

eth0 leva ao mundo externo e tun0 a uma rede openvpn de VMs na qual fica o servidor de aplicativos.

ip r para o gateway da VPN:

default via $outerGatewayAddress dev eth0  metric 100
10.1.0.0/18 dev eth0  proto kernel  scope link  src 10.1.63.254
10.1.64.0/18 dev eth0  proto kernel  scope link  src 10.1.127.254
10.8.1.0/24 via 10.8.1.2 dev tun0
10.8.1.2 dev tun0  proto kernel  scope link  src 10.8.1.1
10.9.0.0/28 via 10.8.1.2 dev tun0
$addressEndingWithAZero/26 dev eth0  proto kernel  scope link  src $vpnGatewayAddress

ip r no servidor de aplicativos:

default via 10.1.63.254 dev eth0  metric 100
10.1.0.0/18 dev eth0  proto kernel  scope link  src 10.1.4.20

Regras do firewall:

Chain PREROUTING (policy ACCEPT 380M packets, 400G bytes) 
pkts bytes target prot opt in out source destination 

Chain INPUT (policy ACCEPT 127M packets, 9401M bytes) 
pkts bytes target prot opt in out source destination 

Chain OUTPUT (policy ACCEPT 1876K packets, 137M bytes) 
pkts bytes target prot opt in out source destination 

Chain POSTROUTING (policy ACCEPT 223M packets, 389G bytes) 
pkts bytes target prot opt in out source destination 

32M 1921M MASQUERADE all -- * eth0 10.1.0.0/17 0.0.0.0/0

configuração de redirecionamento:

sysctl net.ipv4.conf.all.send_redirects
net.ipv4.conf.all.send_redirects = 1
sysctl net.ipv4.conf.eth0.send_redirects
net.ipv4.conf.eth0.send_redirects = 1
sysctl net.ipv4.conf.tun0.send_redirects
net.ipv4.conf.tun0.send_redirects = 1

Por que o baile de máscaras falha às vezes? Como posso evitar isso?

networking vpn iptables ip

por greg0ire 11.04.2014 / 16:16

1 resposta

Tags networking vpn iptables ip

Como posso mover a posição relativa do framebuffer ou da tela X? Como verificar o espaço restante em uma partição isolada da linha de comando

score 2 · Accepted Answer

Como discutido nos comentários, parece que o problema era o gateway VPN enviar erradamente redirecionamentos ICMP para o servidor de aplicativos porque definir as configurações de sysctl net.ipv4.conf.all.send_redirects e / ou net.ipv4.conf.eth0.send_redirects para 0 parece ter resolvido o problema. / p>

Não sei por que o gateway da VPN diria ao servidor do aplicativo para passar pelo gateway externo que o servidor de aplicativos não pode acessar sem passar pelo servidor VPN.