ICMP ECHO REPLY não está sendo SNATed corretamente

Question

Estou tentando fornecer conectividade L3 entre duas redes LAN remotas (10.0.0.0/24, 10.0.1.0/24) usando o OpenVPN com a seguinte configuração:

+----------------+  +---------------------+  +---------------------+
|VM A            |  |VM B (OpenVPN Server)|  |VM C (OpenVPN Client)|
|eth0:10.0.0.5/24|--|eth0:10.0.0.4/24     |  |eth0:10.0.1.4/24     |
+----------------+  |tun0:10.8.0.1/32     |==|tun0:10.8.0.2/32     |
                    +---------------------+  +---------------------+

Fornecendo a seguinte regra de tabela de IP:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 10.0.0.4

Ping VMC- > VMA (10.0.0.5) O IP da solicitação de eco ICMP é SNATed corretamente na VM B:

VM-B# tcpdump -i eth0 icmp
09:27:36.170555 IP 10.0.0.4 > 10.0.0.5: ICMP echo request, id 4049, seq 2, length 64
09:27:36.171201 IP 10.0.0.5 > 10.0.0.4: ICMP echo reply, id 4049, seq 2, length 64

Mas o IP de resposta do eco do VMA- > VMC (10.0.1.4) não é SNATed na VM B:

VM-B# tcpdump -i eth0 icmp
09:33:31.791095 IP 10.0.0.5 > 10.0.1.4: ICMP echo request, id 6590, seq 2, length 64
09:33:31.795299 IP 10.0.1.4 > 10.0.0.5: ICMP echo reply, id 6590, seq 2, length 64

que, no meu caso, resulta em descartar o pacote por outras regras do iptables anti-spoofing subjacentes (máquina host da VM) para evitar spoofing de IP.

Eu não entendo porque o pacote de resposta de eco do ICMP não está sendo apropriadamente SNATed e como fazer isso acontecer. Obrigado.

    

Answer 1

A resposta de eco do ICMP é a metade de retorno de uma conexão, e eles são tratados de maneira diferente, por um motivo.

Primeiramente, se você fez conseguir fazer o que deseja, você quebraria o PING: o VMA enviaria uma solicitação de eco ICMP para 10.0.1.4 , mas receberia uma resposta de eco ICMP (PONG ) de 10.0.0.4 . Ele não associaria esse PONG ao PING enviado anteriormente, então você veria 100% de perda de pacotes (mais PONGs gratuitos).

A maneira de lidar com SNAT em retornos é fazer DNAT em outbounds, e deixar a lógica de limpeza NAT tratar com o tráfego NAT de retorno. Mas você não pode fazer isso aqui, porque se você DNAT tudo entrando em eth0 do VMB para 10.0.0.4 , você não será capaz de falar com VMB por mais tempo.

Portanto, a coisa certa a fazer é corrigir o problema subjacente e fazer com que a lógica de detecção de Marte de seu host se encaixe no seu esquema de endereçamento IP real.