Há muitas perguntas aqui sobre as configurações do iptables DNAT / SNAT, mas eu não encontrei uma que resolvesse meu problema atual.
Tenho serviços vinculados ao endereço IP da eth0 (por exemplo, 192.168.0.20) e também tenho um endereço IP na eth0: 0 (192.168.0.40) que é compartilhado com outro servidor. Apenas um servidor está ativo, portanto, essa interface de alias vem e vai dependendo de qual servidor está ativo. Para obter o tráfego 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
Eu 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 de 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 essa.
[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 a origem.
Estou a pensar que posso configurar uma regra NOTRACK na tabela não processada para evitar conntracking para este número de porta, mas existe uma maneira melhor ou mais eficiente de o fazer funcionar?
Editar - pergunta alternativa: Existe uma maneira (no CentOS / Linux) de ter uma interface que pode ser ligada mas não usada, de modo que possa ser anexada à rede ou desconectada quando um endereço IP compartilhado é trocado entre servidores?
Eu encontrei uma solução para o meu problema.
Usando o parâmetro do kernel net.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. O ARP etc. é tratado pelo ucarp / networking. Com isso em vigor, nenhuma regra DNAT / SNAT é necessária.
Eu posso sugerir duas alternativas, você pode escolher uma delas ou a sua própria.
Você pode configurar seu serviço para ouvir o endereço curinga e, assim, evitar completamente a regra DNAT. A regra SNAT será então aplicada nos pacotes de saída.
Ou, dependendo de qual solução de HA você está usando, você pode configurá-lo 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 em CARP OpenBSD . Com o CARP você tem o IP virtual configurado em todos os nós, mas está ativo em apenas um. Isso significa que você pode ter seu serviço escutando no 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 atualizá-lo) e usar arptables para desabilitar as respostas ou anúncios do ARP para esse IP. Você pode então habilitar ou desabilitar a regra ARP quando um nó se torna um mestre ou escravo.