Há muitas perguntas aqui sobre as configurações do iptables DNAT/SNAT, mas não encontrei nenhuma que resolva meu problema atual.
Tenho serviços vinculados ao endereço IP de eth0 (por exemplo, 192.168.0.20) e também tenho um endereço IP em eth0:0 (192.168.0.40) que é compartilhado com outro servidor. Apenas um servidor está ativo, portanto essa interface de alias vai e vem dependendo de qual servidor está ativo. Para que o tráfego seja aceito pelo serviço, uma regra DNAT é usada para alterar o IP de destino.
iptables -t nat -A PREROUTING -d 192.168.0.40 -p udp --dport 7100 -j DNAT --to-destination 192.168.0.20
Também desejo que todo o tráfego de saída deste serviço pareça vir do IP compartilhado, para que as respostas de retorno funcionem no caso de um failover em espera ativa.
iptables -t nat -A POSTROUTING -p udp --sport 7100 -j SNAT --to-source 192.168.0.40
Meu problema é que a regra SNAT nem sempre é executada. O tráfego de entrada causa uma entrada de rastreamento de conexão como esta.
[root]# conntrack -L -p udp
udp 17 170 src=192.168.0.185 dst=192.168.0.40 sport=7100 dport=7100 src=192.168.0.20 dst=192.168.0.185 sport=7100 dport=7100 [ASSURED] mark=0 secmark=0 use=2
o que significa que a cadeia POSTROUTING não é executada e o tráfego de saída sai com o endereço IP real como origem.
Estou pensando que posso configurar uma regra NOTRACK na tabela bruta para evitar o rastreamento desse número de porta, mas existe uma maneira melhor ou mais eficiente de fazer isso funcionar?
Editar - Pergunta alternativa: Existe uma maneira (no CentOS/Linux) de ter uma interface que possa ser vinculada, mas não usada, de modo que possa ser anexada à rede ou desconectada quando um endereço IP compartilhado é trocado entre servidores?
Responder1
Encontrei uma solução para o meu problema.
Usando o parâmetro do kernelnet.ipv4.ip_nonlocal_bind=1, posso fazer com que meu serviço seja vinculado a endereços que ainda não existem.
Quando a interface eth0:0 é ativada, o tráfego é aceito pelo serviço. ARP etc. é tratado por ucarp/networking. Com isto em vigor, não são necessárias quaisquer regras DNAT/SNAT.
Responder2
Posso sugerir duas alternativas: você pode escolher uma delas ou a sua própria.
Você pode configurar seu serviço para escutar o endereço curinga e, assim, evitar completamente a regra DNAT. A regra SNAT será então aplicada aos pacotes de saída.
Ou, dependendo da solução de HA que você está usando, você pode configurá-la para iniciar seu serviço escutando no IP flutuante (192.168.0.40) à medida que ele é migrado.
Nota não tão relacionada, mas esse tipo de incômodo não existe emCarpa do OpenBSD. Com o CARP você tem o IP virtual configurado em todos os nós, mas ele está ativo em apenas um. É claro que isso significa que você pode ter seu serviço escutando o IP virtual em todos os nós.
Isso não é tão bonito, mas você pode configurar o IP virtual em todos os nós (e até mesmo ativá-lo) e usá-lo arptablespara desabilitar respostas ou anúncios ARP para esse IP. Você pode então fazer com que o ucarp habilite ou desabilite a regra ARP conforme um nó se torna mestre ou escravo.