PFSYNC und Virt. IPs PFS 2.3.2

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