1: 1 Versão do kernel NAT sem estado 3.16 ou posterior usando TC

4

Estou tentando o tráfego NAT sem estado 1: 1. O tráfego está chegando por meio de um túnel GRE e saindo por uma VPN.

Eu fiz pesquisas suficientes para entender que o tráfego que entra em uma caixa linux do túnel GRE não atinge o Conntrack e também não atinge o iptables -t nat. iptales SNAT, DNAT ou NETMAP todos são obrigados a estar na tabela -t nat.

Houve uma opção nat iproute2 stateless, mas foi removida na versão 2.6 do kernel. Antes disso, você poderia fazer um ip route add nat 192.168.50.2 via 192.168.60.2

Quando o nat sem estado foi removido do iproute2, havia uma opção RAWDNAT e RAWSNAT no pacote Xtables-addons. Xtables-addons . A documentação do Xtables-addons ainda oferece RAWDNAT e RAWSNAT como opções, mas eles lançam erros e Xtables-addons remove RAWSNAT / RAWDNAT

Então, isso agora me colocou no mundo do controle de tráfego. A documentação de controle de tráfego é muito esparsa e difícil de seguir. Especialmente para o manuseio de ingresso.

Então eu tenho quebrado o problema e agora estou apenas tentando obter um nat simples e sem estado 1: 1 usando tc sobre minha eth0. Eu tenho uma caixa que tem um endereço 192.168.234.5 e uma rota para 10.40.0.0/16. Estou tentando nat 192.168.234.112 para 10.40.0.112, em ambas as direções.

Para o pacote de entrada vindo de 10.40.0.112:

tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 10 \
  u32 match ip src 10.40.0.112/32 \
  action nat ingress 10.40.0.112/32 192.168.234.112

e para pacotes de saída

tc qdisc add dev eth0 root handle 1: htb
tc filter add dev eth1 parent 1: protocol ip prio 10 \
   u32 match ip dst 192.168.234.112/32 \
   action nat egress 192.168.234.112/32 10.40.0.112 

De alguma forma eu consegui fazer com que os comandos acima funcionassem, mas pela minha vida não consigo mais fazê-los funcionar. Eu encontrei um post no stackoverflow.com que tinha declarado algo sobre o padrão qdisc no Ubuntu (pfifo_fast) é classless por isso não prevê a filtragem de pacotes, mas eu não posso mais seguir esse post. Você poderia pensar que "tc filter add" forneceria uma mensagem de erro se você adicionar a um qdisc que não suporte filtros, mas isso parece ter sucesso.

Então, aqui estão os comandos que estou executando:

adicione o qdisc de saída primeiro para que o ingresso tenha algo para anexar

tc qdisc add dev eth0 root handle 1: htb
tc qdisc add dev eth0 ingress

Neste momento tc qdisc relatórios

qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 0 direct_packets_stat 9 direct_qlen 1000
qdisc ingress ffff: dev eth0 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Agora adicionando o filtro de ingresso como:

tc filter add dev eth0 parent ffff: protocol ip prio 10 \
   u32 match ip src 10.40.0.112/32 \
   action nat ingress 10.40.0.112/32 192.168.234.112

Neste ponto, se eu pingar 10.40.0.112, esperaria que a resposta viesse de 192.168.234.112. Mas o filtro nunca é atingido. Na verdade, nunca vejo a ação nat aplicada ao pacote, mas as estatísticas dessa regra de filtro aumentam.

Eu adicionaria o filtro de saída como:

tc filter add dev eth0 parent 1: protocol ip prio 10 \ 
   u32 match ip dst 192.168.234.112/32 \
   action nat egress 192.168.234.112/32 10.40.0.112

Neste ponto, os filtros tc parecem:

root@ubusswan1-VirtualBox:/home/ubusswan1# tc filter show dev eth0
filter parent 1: protocol ip pref 10 u32 
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? 
  match c0a8ea70/ffffffff at 16
    action order 1:  nat egress 192.168.234.112/32 10.40.0.112 pass
root@ubusswan1-VirtualBox:/home/ubusswan1# tc filter show dev eth0 root
filter parent ffff: protocol ip pref 10 u32 
filter parent ffff: protocol ip pref 10 u32 fh 800: ht divisor 1 
filter parent ffff: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? 
  match 0a280070/ffffffff at 12
    action order 1:  nat ingress 10.40.0.112/32 192.168.234.112 pass 

Você pode me ajudar a entender bem o suficiente para fazer esse 1: 1 nat acontecer? Também existe uma maneira melhor de depurar filtros tc que não estão funcionando?

    
por Brad Rhodes 15.12.2015 / 08:47

1 resposta

2

Acho que você trocou as correspondências src e dst . Eu tenho por agora:

#tc qdisc del dev eth0 ingress
#tc qdisc del dev eth0 root

tc qdisc add dev eth0 root handle 1: htb
tc qdisc add dev eth0 ingress

tc filter add dev eth0 parent ffff: protocol ip prio 1 u32 match ip dst $FROMIP action nat ingress $FROMIP $TOIP
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src $TOIP action nat egress $TOIP $FROMIP

#tc -s qdisc show dev eth0
#tc -s filter show dev eth0
#tc -s filter show dev eth0 parent ffff:

E isso parece funcionar (eu não sou nenhum especialista em tc )!

    
por 08.05.2016 / 09:19

Tags