Es gibt hier viele Fragen zu iptables DNAT/SNAT-Setups, aber ich habe keine gefunden, die mein aktuelles Problem löst.
Ich habe Dienste, die an die IP-Adresse eth0 gebunden sind (z. B. 192.168.0.20), und ich habe auch eine IP-Adresse auf eth0:0 (192.168.0.40), die mit einem anderen Server geteilt wird. Nur ein Server ist aktiv, daher kommt und geht diese Alias-Schnittstelle, je nachdem, welcher Server aktiv ist. Damit der Datenverkehr vom Dienst akzeptiert wird, wird eine DNAT-Regel verwendet, um die Ziel-IP zu ändern.
iptables -t nat -A PREROUTING -d 192.168.0.40 -p udp --dport 7100 -j DNAT --to-destination 192.168.0.20
Ich möchte außerdem, dass der gesamte ausgehende Datenverkehr dieses Dienstes so aussieht, als käme er von der gemeinsam genutzten IP-Adresse, sodass im Falle eines Active-Standby-Failovers die Rückgaben funktionieren.
iptables -t nat -A POSTROUTING -p udp --sport 7100 -j SNAT --to-source 192.168.0.40
Mein Problem ist, dass die SNAT-Regel nicht immer ausgeführt wird. Eingehender Datenverkehr verursacht einen Verbindungsverfolgungseintrag wie diesen.
[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
Dies bedeutet, dass die POSTROUTING-Kette nicht ausgeführt wird und der ausgehende Datenverkehr die echte IP-Adresse als Quelle hat.
Ich denke, ich kann eine NOTRACK-Regel in der Rohtabelle einrichten, um Conntracking für diese Portnummer zu verhindern, aber gibt es eine bessere oder effizientere Möglichkeit, dies zum Laufen zu bringen?
Bearbeiten – Alternative Frage: Gibt es eine Möglichkeit (in CentOS/Linux), eine Schnittstelle zu haben, an die gebunden, die aber nicht verwendet werden kann, sodass sie an das Netzwerk angeschlossen oder getrennt werden kann, wenn eine gemeinsame IP-Adresse zwischen Servern ausgetauscht wird?
Antwort1
Ich habe eine Lösung für mein Problem gefunden.
Durch die Verwendung des Kernelparametersnet.ipv4.ip_nonlocal_bind=1kann ich meinen Dienst dazu bringen, sich an Adressen zu binden, die noch nicht existieren.
Wenn die Schnittstelle eth0:0 aktiviert ist, wird der Datenverkehr vom Dienst akzeptiert. ARP usw. wird von ucarp/networking gehandhabt. Wenn dies vorhanden ist, sind überhaupt keine DNAT/SNAT-Regeln erforderlich.
Antwort2
Ich kann Ihnen zwei Alternativen vorschlagen. Sie können eine davon oder Ihre eigene auswählen.
Sie können Ihren Dienst so einrichten, dass er auf die Wildcard-Adresse hört und so die DNAT-Regel vollständig umgeht. Die SNAT-Regel wird dann auf die ausgehenden Pakete angewendet.
Oder Sie können es – abhängig von der von Ihnen verwendeten HA-Lösung – so konfigurieren, dass Ihr Dienst während der Migration auf der Floating-IP (192.168.0.40) lauscht.
Nicht so verwandte Anmerkung, aber diese Art von Belästigung existiert nicht inOpenBSD CARP. Mit CARP haben Sie die virtuelle IP auf allen Knoten konfiguriert, aber sie ist nur auf einem aktiv. Das bedeutet natürlich, dass Ihr Dienst auf allen Knoten auf der virtuellen IP lauschen kann.
Das ist nicht so schön, aber Sie können die virtuelle IP auf allen Knoten konfigurieren (und sogar aufrufen) und verwenden, arptablesum ARP-Antworten oder Ankündigungen für diese IP zu deaktivieren. Sie können dann ucarp die ARP-Regel aktivieren oder deaktivieren lassen, wenn ein Knoten zum Master oder Slave wird.