Re: outgoing IP ändern?
Hallo,
>> lists@thohal.de:
>
>Ich habe doch ein ordentliches Mail From gesetzt? Zumindest zeigt das
>mein MUA so an?!
Ja hast du. Meine Software hat den Reply-To Header ausgewertet...
Also, ich verstehe dein Szenario so. Bitte korrigieren, wenn ich falsch
liege:
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. Eine TCP-Verbindung identifiziert sich
netzweit eindeutig durch die Absender- und Ziel-IP- und -Portnummern.
Antwortpakete innerhalb einer existierenden Verbindung müssen daher
immer die gleichen IP- und Portnummern wie das initiale SYN Paket
verwenden, nur eben in vertauschter Richtung.
Es muss irgend eine zusätzliche Störungsquelle geben, die ich bisher
nicht sehe.
>_Genau das_ ist mein Problem. Ich kann nicht connecten auf den Port,
>obwohl
>--new, established gesetzt ist
Wenn du mit dem State Match Modul von Netfilter arbeitest, brauchst
du ein -m state --state new von A nach E und ein --state established
in beide Richtungen.
>mit tcpdump auf dem zielhost sehe ich, dass die Pakete (HTTP, Port 80
>tcp) als Source die Physical IP von eth0 tragen.
Ist mit Zielhost die Maschine C gemeint? Wie sehen die eingehenden
Pakete dort aus? Sind hier eventuell weitere Netfilter-Regeln gesetzt?
Oder kann es sein, dass auf dem Host C einfach kein Dienst auf Adresse
E lauscht und der Verbindungsaufbau deswegen mit einem TCP RST oder
einem ICMP Port Unreachable beantwortet wird?
Was sagt denn "lsof -i" auf dem aktiven Knoten?
>Daswegen wiederum werden die Packages gedropped an dem Quellrechner.
Werden die Pakete bei Host A oder an der Firewall B gedroppt?
>Müssen hier unsere Firewalls anziehen, weswegen ich für dieses Problem
>aktuell eine Lösung suche.
Was bedeutet "anziehen"? Das Regelwerk verschärfen?
>Generell könnte ich natürlich alle IPs freigeben, was mir aber nicht
>wirklich sinnig erscheint, da es ja nur um den Service an sich geht...
Richtig. Ich betreibe Setups wie dieses hier dutzendfach bei Kunden
und bin mir absolut sicher, dass nichts anderes als die Dienstadresse
(hier: E) an der Firewall erlaubt werden muss.
>ne, reines gutes braves tcp.. Geht um nen Webservice der zwischen 2
>Hosts "wandert" und egal wo er liegt, kriegt ich die Antworten von der
>physical IP anstatt von der Service-IP :-(
Nochmal, TCP antwortet immer mit der IP-Adresse, auf der die Verbindung
eröffnet wurde. Da muss etwas anderes sein...
>> Hier gibt fast immer eine Konfigurationsoption
>> für die zu verwendende ausgehende Adresse.
>
>Hmm, bei Indianer auch? :-)
Nein. Der Apache baut ja selbst keine Verbindugen auf, sondern beantwortet
nur Requests auf eingehenden Verbindungen.
Okay, es gibt ein paar exotische Konfigurationen, in der der Apache
auch ausgehende Verbindungen aufbaut, z.B. mit mod_proxy oder
mod_auth_ldap, aber das ist nicht der Normalfall.
>Da wird das doch nur über Listen xyz:Port geregelt?
Listen gibt an, auf welchen Adressen der Apache ansprechbar ist.
Hier muss natürlich die Adresse E oder ein * eingetragen sein, ansonsten
ist der Apache über die Dienstadresse nicht erreichbar.
>Hmm - sind leider XEN-Instanzen.... Aber mal so:
Was sind Xen Instanzen? Die Server C und D?
Wie sind sie mit der Außenwelt vernetzt?
>Kann ich das nicht mittels iptables und SNAT gerade ziehen?
Das könnte man bestimmt, aber dazu müsste man erstmal wissen wo denn
genau der Fehler auftritt und worin er besteht. Mir ist das ehrlich
gesagt immer noch nicht so recht klar.
Gruß, Harald
Reply to: