Hay muchas preguntas aquí sobre las configuraciones DNAT/SNAT de iptables, pero no he encontrado ninguna que resuelva mi problema actual.
Tengo servicios vinculados a la dirección IP de eth0 (por ejemplo, 192.168.0.20) y también tengo una dirección IP en eth0:0 (192.168.0.40) que se comparte con otro servidor. Sólo hay un servidor activo, por lo que esta interfaz de alias aparece y desaparece según el servidor que esté activo. Para que el servicio acepte el tráfico, se utiliza una regla DNAT para cambiar la 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
También deseo que todo el tráfico saliente de este servicio parezca provenir de la IP compartida, de modo que las respuestas de retorno funcionen en caso de una conmutación por error activo-en espera.
iptables -t nat -A POSTROUTING -p udp --sport 7100 -j SNAT --to-source 192.168.0.40
Mi problema es que la regla SNAT no siempre se ejecuta. El tráfico entrante provoca una entrada de seguimiento de conexión 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
lo que significa que la cadena POSTROUTING no se ejecuta y el tráfico saliente sale con la dirección IP real como fuente.
Estoy pensando que puedo configurar una regla NOTRACK en la tabla sin formato para evitar el seguimiento de conexiones para este número de puerto, pero ¿existe una manera mejor o más eficiente de hacer que esto funcione?
Editar - Pregunta alternativa: ¿Hay alguna manera (en CentOS/Linux) de tener una interfaz que pueda vincularse pero no usarse, de modo que pueda conectarse a la red o desconectarse cuando se intercambia una dirección IP compartida entre servidores?
Respuesta1
He encontrado una solución a mi problema.
Usando el parámetro del kernelnet.ipv4.ip_nonlocal_bind=1, puedo hacer que mi servicio se vincule a direcciones que aún no existen.
Cuando se activa la interfaz eth0:0, el servicio acepta el tráfico. ARP, etc. es manejado por ucarp/networking. Una vez implementado esto, no se necesitan reglas DNAT/SNAT en absoluto.
Respuesta2
Puedo sugerir dos alternativas, puedes elegir una de ellas o la tuya propia.
Puede configurar su servicio para escuchar en la dirección comodín y así evitar por completo la regla DNAT. Luego, la regla SNAT se aplicará a los paquetes salientes.
O, dependiendo de la solución HA que esté utilizando, puede configurarla para que su servicio comience a escuchar en la IP flotante (192.168.0.40) a medida que se migra.
Nota no tan relacionada, pero este tipo de molestias no existen enCARPA OpenBSD. Con CARP tienes la IP virtual configurada en todos los nodos, pero está activa solo en uno. Por supuesto, esto significa que puede tener su servicio escuchando en la IP virtual en todos los nodos.
Esto no es tan bonito, pero puede configurar la IP virtual en todos los nodos (e incluso abrirla) y usarla arptablespara deshabilitar las respuestas o anuncios ARP para esa IP. Luego puede hacer que ucarp habilite o deshabilite la regla ARP cuando un nodo se convierte en maestro o esclavo.