PFSYNC und Virt. IPs PFS 2.3.2

trixters

ok ein Beispiel:

die FWs arbeiten als HA mit der 100.2 und 100.3 - die Carp-IP ist die 100.1 als Gateway für Externe.
wenn man nun nicht die 100.1, sondern die 100.10 für Externe Dienste nutzen möchte braucht es Virt-IPs, sofern man nicht die Kiste direkt nach draußen stellen will.

Mein Problem ist nun, dass die 100.10 sich zwar auf der primären HA-Instanz anlegen lässt die sekundäre diese aber nicht "lernt"- geschweige denn übernimmt im Ausfall.
Bricht nun die primäre Fw weg, so ist der Dienst auch nicht mehr erreichbar ;(

"Stacked IP Alias VIPs will synchronize via XMLRPC"

Der Sinn hinter HA ist ja gerade die Erreichbarkeit trotzt Ausfall, welche hier aber nicht gegeben ist.

JeGr

"Stacked IP Alias VIPs will synchronize via XMLRPC"

Richtig. Stacked IP Aliases.
Anstatt mehrfach zu wiederholen was nicht geht, hätte genügt zu sagen, wie es jetzt konfiguriert ist anstatt zu erklären dass es nicht geht.

Für das was du möchtest, muss:

eine CARP VIP auf einem physikalischen Interface definiert sein
die Vip sauber auf den Backup Node synchronisiert werden
dann eine Alias IP angelegt werden mit Basis auf der CARP VIP - NICHT auf dem physikalischen Interface!

danach prüfen ob diese Alias IP sauber auf den Backup Node kommt. Wichtig dabei ist, dass es wie unter der Doku Seite angegeben eine ALIAS IP ist und kein Proxy Arp oder sonstwas. Zusätzlich muss die Alias IP auf der CARP VIP als Interface definiert sein, nur dann funktioniert sie als Alias der VIP und folgt dieser auch bei einem Failover auf den anderen Knoten.

Und genau so funktioniert das bei uns auch mit ca. 30 zusätzlichen Adressen. :)

Der Sinn hinter HA ist ja gerade die Erreichbarkeit trotzt Ausfall, welche hier aber nicht gegeben ist.

Doch genau der ist gegeben, wenn man sich an die Doku hält: ;)

Zitat:

IP Alias style IPs
(…)

Can be used for NAT.
Can be used by the firewall itself to bind/run services.
Adds extra IP addresses to an interface.
(...)
Can be stacked on top of a CARP VIP to bypass VHID limits and lower the amount of CARP heartbeat traffic.
Stacked IP Alias VIPs will synchronize via XMLRPC.
Stacked IP Alias VIPs must be inside the same subnet as the CARP VIP upon which they are placed.

Grüße

trixters

JeGr du Scherzkeks, hast du den eingangspost denn gelesen ?

ich habe leider den Eindruck dem wäre nicht so - eben deswegen wiederhole ich die entsprechenden Passagen:

eine CARP VIP auf einem physikalischen Interface definiert sein
Hab ich - sonst würde CARP ja nicht laufen
die Vip sauber auf den Backup Node synchronisiert werden
Die CARP-VIPs kommen rüber, die IP Alias - Adressen (die laut Doku eben auch unter V-IPs fallen) eben nicht ;(
dann eine Alias IP angelegt werden mit Basis auf der CARP VIP - NICHT auf dem physikalischen Interface!
Du Ei, das "lernen" die automatisch beim Anlegen vom CARP-Interface: Virtual IP Password / VHID Group / Advertising frequency - sind ausgegraut, sofern dargestellt identisch mit CARP.

JeGr

Du Ei, das "lernen" die automatisch beim Anlegen vom CARP-Interface: Virtual IP Password / VHID Group / Advertising frequency - sind ausgegraut, sofern dargestellt identisch mit CARP.

Bevor du anderen irgendwelche Bezeichnungen hinterherwirfst könntest du

mal deine Interfaces richtig beschreiben
Screens davon posten, wie deine Aliases konfiguriert sind
das ggf von beiden Knoten
den CARP Status und die Interface Alias Liste zeigen

anstatt hier lustig immer wieder rumzunörgeln, dass dir die Hilfe nicht gefällt. Ich habe versucht dir zu helfen und nehme dabei eben auch manchmal kein Blatt vor den Mund. Das ist nicht persönlich, aber man kann auch manchmal so einen Tag haben. Mir aber ständig zu erklären dass du eh alles richtig machst, hilft weder dir noch mir.

Und irgendwas "lernen" tut eine AliasIP nicht. Du konfigurierst sie richtig oder eben nicht. Und was du beschreibst - dass es ausgegraut wird - hat nichts damit zu tun, was DU bei INTERFACE auswählst. Wählst du das physikalische Interface - wird die Alias VIP nicht übernommen. Wählst du da aber dein vorher korrekt eingerichtetes CARP Interface wird die VIP auch mit rübergezogen.

Dann steht bei dieser VIP in der Alias Liste auch nicht das Interface mit Namen, sondern die IP und die Beschreibung der CARP VIP dahinter. Und dann wird die auch auf den Backup Node gesynct - du Ei ;)

Gerade eben in unserem Office Cluster auf 2.3.2 nochmal durchgespielt:

CARP VIP für internes LAN -> 10.x.y.254/24
neue VIP
TYP IP ALIAS
Interface Dropdown -> CARP VIP .254 ausgewählt
IP rein 10.x.y.234/24 ; Beschreibung Testy Test
Speichern
Backup Node aufmachen
TADA -> VIP Alias Testy Test ist da.

Gruß

trixters

Mir ist unwohl dabei Innereien eines Produktivsystems zu posten - das mag mein innerer Datenschützer nicht.

versuchen wirs mal so:
Tada :

Sep 15 14:28:05 kernel carp: VHID 4@em3: MASTER -> BACKUP (more frequent advertisement received)
Sep 15 14:28:05 kernel carp: VHID 5@em4: MASTER -> BACKUP (more frequent advertisement received)
Sep 15 14:28:05 kernel carp: VHID 1@em0: MASTER -> BACKUP (more frequent advertisement received)
Sep 15 14:28:05 kernel carp: VHID 2@em1: MASTER -> BACKUP (more frequent advertisement received)
Sep 15 14:28:05 kernel carp: VHID 6@em5: MASTER -> BACKUP (more frequent advertisement received)
Sep 15 14:28:05 kernel carp: VHID 3@em2: MASTER -> BACKUP (more frequent advertisement received)
Sep 15 12:28:05 check_reload_status Carp backup event

heißt dann wohl - CARP funktioniert ?

Jetzt hängt man den Alias ans CARP ?

Das muss einem ja mal gesagt werden - bin bisher davon aus, dass die Daten unten dafür sorgen, dass der Alias mit umzieht.
Allerdings verstehe ich dann nicht wozu diese Daten dann angezeigt werden ?

Aber so wie Du das erklärst, macht das durchaus Sinn, dass der Alias Huckepack aufs CARP mit drauf muss.

Also erst mal danke für Deine Hilfe, das war erhellend ;D

Ich hab bisher mit diesen Hot-Standby-Lösungen gearbeitet, die spiegeln ja einfach die Konfig durch und nur einer im Cluster ist up - das ist eben eine andere (einfachere) Denke.

Mal eine andere Frage on Top: Versteht der "Virtual Server" des Load-Balancers auch HA ? Woher weiß der wo er gerade aktiv sein muss ?
Die Doku ist da leider nicht sehr auskunftsfreudig und im Netz findet sich meist "dual-WAN-Load-Balance" nett, aber ich möchte nur ein Serverpäärchen aus der DMZ "draußen" verfügbar machen, inkl. Fault-Tollerance. - bisschen viel Schlagwort-Bingo heute, sorry :o

Konstellation:

-Virtual Server im Netz vom externen Interface

-Rules lassen den Zugiff von extern auf den Virtual Server zu

-Rules lassen den Zugiff vom Virtual Server zu den internen Servern zu

extra NAT und co braucht es nicht ?

Alias.jpg_thumb

JeGr

Mir ist unwohl dabei Innereien eines Produktivsystems zu posten - das mag mein innerer Datenschützer nicht.

Niemand sagt, dass du Sachen nicht ausschwärzen kannst.

Das muss einem ja mal gesagt werden - bin bisher davon aus, dass die Daten unten dafür sorgen, dass der Alias mit umzieht.
Allerdings verstehe ich dann nicht wozu diese Daten dann angezeigt werden ?

Darum hab ich das ja mehrfach geschrieben - du wolltest nur nicht lesen :P Den Punkt hatte ich aber mehrfach betont: der ALIAS muss auf die CARP VIP obenauf, NICHT aufs physikalische Interface.
Die Daten die ausgegraut sind werden überhaupt nicht angezeigt, die sind überflüssig - deshalb werden sie auch ausgegraut. Alias IPs haben gar nichts mit VIPs etc. zu tun und haben deshalb auch keine derlei Eigenschaften. Das sind einfach zusätzliche IPs auf einem Interface. Was bei Linux bspw. ein eth0:1 o.ä. oder unter Windows eine zweite konfigurierte IP wäre. Meine Kiste soll nicht nur unter .1 sondern auch unter .9 erreichbar sein? Alias drauf, done.
Deshalb zieht ein "normales" Alias auch nicht einfach um, denn es ist ein Alias für das physikalische Interface. Darum muss das Alias auf die VIP drauf, damit es dann auch mit der VIP umzieht. Dafür kann man mit Aliasen ein paar Schweinereien machen, die sonst nicht möglich sind (bspw. die Netzmasken- oder Netzdefinitions-IP nutzen ;))

Also erst mal danke für Deine Hilfe, das war erhellend ;D

Manchmal brauchts eben den Holzhammer :P :o ;D

Ich hab bisher mit diesen Hot-Standby-Lösungen gearbeitet, die spiegeln ja einfach die Konfig durch und nur einer im Cluster ist up - das ist eben eine andere (einfachere) Denke.

Jein, pfSense ist an der Stelle ja fast genauso. Der einzige Punkt wo es sich unterscheidet ist, dass es einige wenige Punkte gibt, die auf beiden Clusterknoten ausgeführt werden müssen. Physikalische Interfacezuordnung bspw. gehört da hinzu, ebenso wie ein gewisses Grundsetup.

Mal eine andere Frage on Top: Versteht der "Virtual Server" des Load-Balancers auch HA ? Woher weiß der wo er gerade aktiv sein muss ?

Wenn du mir jetzt sagst, was du mit "Virtual Server" meinst? :)

JeGr

Kurzer Nachtrag zu den VIP/Alias IP Details in Englisch von Jimp:

A couple more points of clarification:

IP Aliases on interfaces directly cannot sync because it creates an IP conflict

IP Aliases using a CARP VIP for their interface will sync – they use the MAC of the CARP VIP and they do not conflict

IP Aliases on Localhost for their interface will sync -- there is no chance of a conflict since it is internal to each node

Proxy ARP VIPs cannot sync in any fashion as it will also create an IP conflict

trixters

Moin JeGr,

so nennt sich der Menü-Punkt - siehe Anhang

![Virt Servers.jpg](/public/imported_attachments/1/Virt Servers.jpg)
![Virt Servers.jpg_thumb](/public/imported_attachments/1/Virt Servers.jpg_thumb)

JeGr

Aaah, das meinst du :) Ich hatte im Geiste schon wieder verdrängt, dass es RelayD ja auch noch gibt und dachte du sprichst schon von sowas wie HAProxy.

Mal eine andere Frage on Top: Versteht der "Virtual Server" des Load-Balancers auch HA ?

Ja, tut er (relayd).
Das "größere" Proxy Paket "HAProxy" könnte es auch.

Woher weiß der wo er gerade aktiv sein muss ?

Weil relayd an der Stelle zum Großteil aus Manipulation von pf Regeln bzw. NATting besteht und das "einfach so" auf den Slave synchronisiert werden kann ohne Probleme zu machen. Da der RelayD Service m.W. intern auf localhost lauscht und durch die NAT Regeln von extern den Traffic zugeschustert bekommt, kann der RelayD somit problemlos auf beiden Nodes laufen ohne dass er auf eine IP gebunden wäre, die nur auf einem Node existiert. Ähnlich wird bspw. auch OpenVPN und Co. im HA Cluster gemanaged: Der Service selbst lauscht entweder auf die VIP (und wird dann nur gestartet wenn der entsprechende Node up ist) ODER er lauscht auf localhost und läuft somit immer und bekommt die Verbindungen via NAT/RDR Regeln in dem Moment, wenn sein Knoten Master wird. Beides ist möglich. Bei RelayD ist es die zweite Variante.

Andere Packages wie OpenVPN oder HAProxy monitoren die CARP VIP und sehen nach, ob die gebunden ist -> wenn ja wird der Service gestartet und done.

Näheres zu RelayD gibts bei: https://calomel.org/relayd.html

Grüße

trixters

Danke JeGr

Ja der HA-Proxy liest sich interessant - ist aber für den gewünschten zweck "oversized".
Fand die idee mit dem Agent für echte Verteilung nach Last schon sehr spannend.
Leider verschwinden Packete ja auch immer wieder, daher möchte ich gern bei den Basics bleiben, soweit es geht.
wobei ich finde das der HA-Proxy besser dokumentiert ist ??? aber das liegt wohl an dessen Einsatzgebiet.

JeGr

Fand die idee mit dem Agent für echte Verteilung nach Last schon sehr spannend.

Ja da lässt sich einiges realisieren damit, was man sonst nur von kommerziellen LBs kennt.

Leider verschwinden Packete ja auch immer wieder, daher möchte ich gern bei den Basics bleiben, soweit es geht.

Wo verschwinden denn Pakete? :O

trixters

Moin JeGr,

ich habe mal mit einem Packet gespielt, dass eine Freeswitch Telefonanlage auf die PF bringen sollte.
Fand ich prinzipiell wirklich gut - so könnte man tatsächlich mit der PF eine FritzBox-Alternative bauen.

Leider ist das Packet dann wieder verschwunden ;(

trixters

Zusammenfassung :

Wenn man Virtuelle IPs in HA Umgebung benutzen möchte:

man nehme

einen IP Alias auf dem man den Service später erreichen möchte
diesen Alias koppelt man unter Interface an das passende CARP-Interface der HA - nicht an das pysikal. Interface!
für die Erreichbarkeit braucht es nun noch einen NAT-Eintrag, der eine "Filter rule association" generieren wird
damit Externe diese externe IP erreichen braucht es abschließend noch eine Roule auf dem externen Interface

ob man alles richtig gemacht hat sieht man erst mal auf dem HA-Slave, dieser müsste duch Sync den Alias übernommen haben.

JeGr

Hi,

für die Erreichbarkeit braucht es nun noch einen NAT-Eintrag, der eine "Filter rule association" generieren wird
damit Externe diese externe IP erreichen braucht es abschließend noch eine Roule auf dem externen Interface

Bist du dir da mit dem ersten Punkt sicher? Da die pfSense selbst ja den Traffic annimmt - Welchen NAT Eintrag musst du dir dann erstellen? Von extern auf localhost?
Und wenn ja und du eingestellt hast, dass für den Eintrag eine Filterregel erstellt wird, warum dann nochmals eine im nächsten Punkt erstellen?

Grüße