[Gelöst] carp cluster - ausgehende IP-Adresse festlegen
-
Hallo,
ohne es selbst zu wissen vermute ich, dass du das bei "Outgoing NAT" einstellen musst, dass er dort immer die VIP verwendet. Vermutlich steht es bei dir noch auf "Automatic NAT".
Also mal auf "Manual NAT" umstellen, dann übernimmt er erst einmal die automatic settings, es geht also nichts "kaputt" und du kannst es anpassen.Soweit ich weiss, stellt man es dort auch entsprechend ein, wenn man mehrere öffentliche IP Adressen hat und diese zu verschiedenen Zwecken nutzen mag.
Grüße
-
Hallo,
ich habe "Outgoing NAT" jetzt auf die vIP umgestellt (stimmen die Einstellungen? siehe Attachment). Dabei habe ich die automatisch erzeugten Einstellungen übernommen und nur die Adresseinstellung von "WAN Address" auf die vIP-Adresse geändert.
Leider hat es nicht geholfen. Im Internet kommt immer noch die xx.xxx.92.44 - also die WAN-Interface Adresse des pfSense-Masters an.
Woran kann das liegen? Wo kann ich weitersuchen?
Danke
Edgar
[Erläuterung zum Screenshot:
192.168.12.0 = LAN
192.168.100.0 = DMZ
192.168.77.0 = WLAN
192.168.254.0 = SYNC]
-
Hallo Edgar,
in deinem OP sind einige seltsame Dinge, ich versuche die mal zu kommentieren, allerdings ist das schwerer als es sein müsste, da du deine Interface- und CARP Konfiguration nicht ganz dargestellt hast. Außerdem ist auch noch relevant, wie die IPs anliegen. Da du ein Gateway im gleichen Netz angibst gehe ich davon aus, dass die IPs nicht geroutet werden.
Master: xx.xxx.97.44
Backup: xx.xxx.97.45
Virtuelle IP am WAN-Interface: xx.xxx.97.42
Gateway: xx.xxx.97.41Du baust also einen CARP Cluster, indem du eine Maschine auf dem WAN mit …97.44 und die zweiten mit ...97.45 baust. Soweit so gut. Am Besten sollten diese Maschinen über ein Crosslink Kabel (direktes Kabel von Node 1 zu 2) auf einem extra Interface verbunden sein, über die dann der CarpSync läuft. Ist das bei dir der Fall? Wenn nicht auf welchem Interface läuft der Sync?
Desweiteren hast du (hoffentlich) eine Virtuelle IP Typ CARP angelegt mit der ...97.42. Korrekt? Wenn nicht, nachholen/korrigieren, die muss den Typ CARP haben und sollte nur auf dem Master angelegt werden, nach erfolgreicher Sync Konfiguration sollte die automatisch auf dem Slave auftauchen.
Ebenfalls wirst du wohl intern (LAN, DMZ und WLAN) noch eine CARP VIP brauchen, denn dein Gateway soll ja nach einem Failover weiter erreichbar sein? Also auch hier Node-IPs konfigurieren und eine CARP VIP. Nach deinem zweiten Posting solltest du also quasi 4 Typ CARP VIPs haben (WAN, LAN, DMZ, WLAN).
- wo (und was) muss ich einstellen, damit die im Internet ankommende IP Adresse die Virtuelle-IP ist, und nicht die der Mastermaschine?
Da hat Kollege @Nachtfalke recht, das regelt sich in den NAT Einstellungen. Diese sehen in deinem obigen Beispiel eigentlich OK aus, allerdings eine kleine Anmerkung: Das Sync Netz brauche eigentlich kein NAT. Hier werden nur Daten zwischen den Nodes ausgetauscht, man möchte auch gar nicht, dass dieser Verkehr mal aus Versehen öffentlich wird. :)
- gilt diese Einstellung dann auch gleich für den umgehrten Weg, also wenn ich ein Portforwarding auf einen internen Rechner erstelle?
Nein, die Outbound NAT hat nichts mit dem Weg nach Drinnen zu tun. Hier muss entweder ein PortForwarding entsprechend konfiguriert werden oder auch ein 1:1 NAT wenn gewünscht auf die entsprechende Public IP, die dafür genutzt werden soll. Die Art der NAT Auswahl bestimmt dann auch, ob noch eine extra Outbound NAT Regel konfiguriert werden muss oder nicht.
Leider hat es nicht geholfen. Im Internet kommt immer noch die xx.xxx.92.44 - also die WAN-Interface Adresse des pfSense-Masters an.
Geprüft von wo aus? Regeln auch neu geladen? Etwas gewartet damit nicht ein vorhandener State genutzt wird und die Ergebnisse verfälscht?
Grüße
Jens -
Hallo (Jens),
Deine Vermutungern bzgl. der Konfiguration sind alle richtig (Screenshots nachgeliefert!)
Das CARP ist über ein Crosslinkkabel verbunden, auf einem extra Interface (IP: 192.168.254.1 und 192.168.254.2), es existieren 4 virtuelle IPs angelegt (siehe Screenshots). Der Sync zwischen den Maschinen funktioniert einwandfrei.Das NAT für "SYNC" werde ich 'rausnehmen.
"Geprüft" habe ich das Ganze hier aus dem LAN (http://www.ipchicken.com/) von verschiedenen Clients aus (LAN-Client, WLAN-Client). Ich hatte die pfSense sogar zwischendrin rebootet um ganz sicher zu gehen.
Bzgl. dem Portforwarding: ich denke es ist sinnvoll zuerst das Problem mit der ausgehenden IP zu lösen und sich dann mit dem Zugang zu den internen Servern zu beschäftigen.
Gruss und Danke für den tollen Support
Edgar
-
Hallo Edgar,
klingt in Textform erstmal alles optimal. Auch in den Screens sehe ich jetzt auf den ersten Blick erst einmal nichts, was da nicht hingehört ;)
Was interessant wäre:- CARP Status: alles auf Master Node und grün? Slave alles grau also nirgends Split Brains?
- Netzmasken überall korrekt (sieht so aus, aber der Teufel ist ein Eichhörnchen)
- Wie sehen die Regeln bspw. auf dem LAN aus? Könnte da noch was begraben liegen?
Grüße
-
Hi Jens,
- CARP Status: alles auf Master Node und grün? Slave alles grau also nirgends Split Brains?
Master ist alles grün, die Slave-Maschine hängt (ausser am Synckabel) gar nicht an den Switchen. Damit will ich vermeiden, dass ich in einem Moment nicht genau weiss, wer Master und wer Backup ist (das kann doch hoffentlich nicht die Ursache des Debakels sein, oder?). Was "Split Brains" sind, weiss ich leider nicht …
- Netzmasken überall korrekt (sieht so aus, aber der Teufel ist ein Eichhörnchen)
mindestens 10 mal überprüft …
- Wie sehen die Regeln bspw. auf dem LAN aus? Könnte da noch was begraben liegen?
Eigentlich gibt's nicht viele Regeln, ich hab' so gut wie alle erstmal deaktiviert …
Macht es Sinn, erstmal alle Regeln und NATs zu löschen?(Mein Problem ist, dass ich den Einbau der pfSense quasi im Laufenden Betrieb vornehmen muss. Deswegen habe ich mir die Maschinen zum Aufbau in mein LAN gehängt (mein LAN war praktisch das WAN), die (Grund-)Einstellungen mit anderen IP-Adressen vorgenommen und dann auf die Originalparameter angepasst.
Jetzt habe ich die Rechner parallel zu den alten (IPCop-) Maschinen dastehen und kann nur wenn hier kein Bürobetrieb ist (also nachts) die Kabel umstecken und an den neuen Maschinen probieren ...)Gruss
Edgar
-
Ahoi,
SplitBrain wäre die Situation bei zwei Netzteilnehmern, die eigentlich im Master/Slave Betrieb laufen sollten, aber beide denken, dass Sie Master sind. Das ist im Falle der pfSense nicht ganz soo schlimm, wenn wir aber bspw. von Dateisystemen reden (bspw. DRBD) und da beide auf einmal denken, dass sie Master sind, kann das zu bösem Datenverlust kommen.
Allerdings würde ich in deinem Fall schon beide Knoten live reinhängen, die Knoten-IPs sind ja disjunkt (sprich jeder hat eine eindeutige) und wenn beide sauber im CARP Verbund hängen, sollte es da keine Probleme geben. Sollte wider erwarten der Slave auf einmal für eine VIP ebenfalls MASTER anzeigen obwohl der Primary Knoten da schon MASTER stehen hat (oder der konfusere Fall: Master zeigt für 3/4 MASTER an, aber für eine IP Standby), dann dringend beide Knoten mal durchbooten (evtl. hat sich dann bei einem Sync was verklemmt, kommt nicht sehr häufig vor und ist eigentlich harmlos). Im Falle des Falles kann man auch immer auf einem der beiden jederzeit den "Disable CARP" Button drücken. Damit lässt der Knoten instant die Finger von den VIPs.
Es wäre aber schon interessant ob - im vollen Betrieb - es bspw. ein CARP Problem gibt, das würde dann nämlich auf darunterliegende Netzwerkprobleme oder Routing etc. schließen lassen.
mindestens 10 mal überprüft …
Glaub ich dir gerne, ist mir aber auch schonmal durchgerutscht ;)
Macht es Sinn, erstmal alle Regeln und NATs zu löschen?
Ggf. schon, allerdings sollten die Outbound NATs natürlich bleiben, sonst geht da gar nichts ;)
Auf LAN/WLAN/DMZ o.ä. solltest du dann auch mind. eine "Allow Any" Default Regel haben, damit dann was raus geht. Darauf dann auch ggf. Logging aktivieren, dann sieht man in den FW Logs auch, ob die Regel greift.Grüße
-
Hi,
damit ergibt sich also für morgen früh folgender Testablauf:
- beide Geräte anstecken, überprüfen was passiert, wenn einzelne Kabel abgezogen werden
- alle Regeln (bis auf "allow any") von allen Interfaces löschen
- alle Portforwardings löschen
- kontrollieren, ob alle Outbound NATs noch da sind (BTW: wofür sind eigentlich die ISAKMP-Regeln mit dem statischen Port 500? von Verschlüsselung reden wit doch noch gar nicht.)
- kontrollieren, welche IP nach draussen übermittelt wird
- Logging für "allow any" aktivieren und FW-Log anschauen
Ich melde mich dann morgen früh wieder (am liebsten mit einem "[Solved]".
Gruss
Edgar -
'morgen,
nachdem ich nun beide pfSense-Maschinen an alle beteiligten Switche angeschlossen habe, wird die richtige IP-Adresse - nämlich die des virtuellen Interfaces - nach draussen übermittelt.
Auch durch wechselseitiges Abziehen der Kabel konnte ich das vorherige Verhalten (IP der Master-pfSense wurde nach draussen übermittelt) nicht mehr reproduzieren. Auch wenn mir der technische Zusammenhang verborgen bleibt, nehme ich an, dass es notwendig ist, bei der Inbetriebnahme eines CARP-Clusters zunächst alle beteiligten NICs mit den entsprechenden Gegenstellen zu verbinden. Steht das Setup, kann die Redundanz durch trennen einer Verbindung getestet werden …
Dieses Problem ist aus meiner Sicht also gelöst.
Was (weiterhin) nicht klappt ist das Erstellen eines Portforwardings in mein Netz:
Ich habe zunächst alle vorher erstellten Regeln gelöscht und nur ein Portforwarding (auf den internen Server 192.168.12.225) eingerichtet. Dazu habe ich mir die FW-Rule automatisch erstellen lassen. (Siehe Anhang).
Ein Zugriffsversuch wird mit Verweis auf die "Default deny rule" geblockt (siehe Anhang).Was habe ich nicht kapiert?
Danke schon wieder für die weitere Unterstützung
Edgar
-
Hi,
du hast in der Portforwarding Regel die WAN address stehen, das sollte die WAN VIP sein.
Grüße
-
Danke, das war die Ursache!
Mit dem Eintrag der vIP funktioniert das Portforwarding einwandfrei. (Ist ja eigentlich auch logisch und ich hätte selber d'raufkommen können).[Besten Dank nochmal an die helfenden Köpfe hier. Es ist wirklich super, dass Ihr Euch die Mühe macht, die Konfigurationen der "hilflosen" nachzuvollziehen und die Lösungen anzubieten. Ohne dieses Forum hätte ich das wohl nicht hinbekommen]
Damit setze ich dann den Thread auf "gelöst".
Edgar
-
Hallo Edgar,
freut mich zu hören und schön, dass du auch gleich den Thread auf gelöst gesetzt hast ;)
@viragomann: toll gesehen und gelöst :)
Grüße
Jens
