On 14.02.2009, at 01:31, Harald Weidner wrote:
Also, ich verstehe dein Szenario so. Bitte korrigieren, wenn ich falschliege: Links ein Desktop-Rechner A mit Webbrowser, in der Mitte eine Firewall B mit Netfilter-Regeln, rechts zwei Rechner C und D mit Heartbeat Cluster und einer virtuellen IP-Adresse E. Über die Clustersoftware wird die Adresse E dem aktiven Knoten zugeordnet und der Apache gestartet. A versucht eine TCP-Verbindung auf Adresse E und Port 80 zu eröffnen. Die Verbindung kommt jedoch nicht zustande, da die Antwortpakete (z.B.) als Absender-IP-Adresse C statt E tragen und sie somit an der Firewall B blockiert werden. Eigentlich kann das nicht sein.
Doch. Genau das passiert wenn in so einem Setup die Adresse des virtuellen Interfaces im gleichen Netz liegt wie die des realen Interfaces.
eth2 Link encap:Ethernet HWaddr 00:C1:26:06:2B:DAinet addr:192.168.1.90 Bcast:192.168.1.255 Mask: 255.255.255.0
inet6 addr: fe80::2c1:26ff:fe06:2bda/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:235912092 errors:0 dropped:0 overruns:0 frame:0
TX packets:204135634 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4286567824 (3.9 GiB) TX bytes:1873495837 (1.7 GiB)
Interrupt:10 Base address:0xe000
eth2:0 Link encap:Ethernet HWaddr 00:C1:26:06:2B:DA
inet addr:192.168.1.92 Bcast:192.168.1.255 Mask:
255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0xe000
17.0.116.237 dev ppp0 proto kernel scope link src 87.166.9.45
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.90
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.90
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
239.0.0.0/8 dev eth0 scope link
default dev ppp0 scope link
Eine Lösung währe mit Hilfe von ip die Source Adresse zu ändern.
ttyl8er, t.k.Attachment:
smime.p7s
Description: S/MIME cryptographic signature