CARP mit normaler Peer-IP

[trixter]

Moin,

habe mit CARP schon so einiges Angestellt und gesehen, was man alles falsch machen kann.

Was mir generell nicht gefällt: CARP verwendet als Default keine gewöhnliche IP, sondern eine Broadcast-Adresse 224.0.0.240.
Dies führt dazu, dass die CARP-Infos über das WAN ausgetauscht werden müssten - weil die Default-Routen diese zum WAN raus schicken.
Interna haben für mich im WAN (öffentlichen Netz) nichts zu suchen.

Also habe ich, wie hier oft empfohlen wird, die direkte Peer-Adresse verwendet.

ABER das führt im zusammen mit HA dazu, dass diese Peer-Adresse auf dem Slave mit dessen eigener überschrieben wird!
Danach gibt es dann 2 Master, weil der Slave sich nie beim eigentlichen zurückmelden kann, denn die Meldung dazu geht ja an ihn selbst....

Habe noch keine wirklich zufriedenstellende Lösung dafür.

Das beste wäre es vermutlich die Peer-IP nicht mit zu synchronisieren, oder 2 IPs eintragen zu können.

Bin für bessere Vorschläge offen.

[Patrick M. Hausen]

Meinst du CARP oder den XMLRPC Sync? Natürlich müssen die beiden Nodes auf jedem Interface, auf dem eine HA-Adresse konfiguriert ist, also in der Regel auch auf WAN, miteinander CARP sprechen. Jedes Interface tut das unabhängig. Die Adresse ist Multicast, kein Broadcast. Und sie wird auch nicht zum Gateway geschickt sondern bleibt immer auf dem jeweiligen Link.

[trixter]

Hi Patrick

ich meine tatsächlich beides, denn sowohl pfsync, als auch Carp nutzen per default 224er Adressen.
Beim Sync (System: High Availability: Settings) kann man zwar ein Interface angeben (Synchronize all states via), aber 224er Adressen landen ja per Default-Route immer am WAN Interface - das finde ich "unglücklich", weil man ja damit die Sync-Updates ins WAN schickt.

Beim Carp verhält es sich ähnlich (Interfaces: Virtual IPs: Settings), auch hier werden per Default 224er Adressen verwendet, die dann ebenfalls beim WAN landen.

Nennt mich ruhig paranoid, aber das ist doch schließlich eine Firewall.
Ich hab es noch nicht ausprobiert, aber ich könnte mir vorstellen, das man durch Packet-Replication Carp gehörig aus dem Tritt bringen könnte?

Habe jetzt versucht diese Broadcasts auf dem Sync-Interface zu halten, indem ich an Stelle der 224er Adressen direkt die Peer-Adresse verwende:

BSP. Peer A 10.0.0.1, Peer B 10.0.0.2

Allerdings wird beim Sync der Config (XMLRPC/pfsync) die Adresse immer überschrieben, das ist bei BCast nicht schlimm, bei direkter Kommunikation aber doof, dann würde Peer B nur noch mit sich selbst reden, weil dies ja in der Config von Peer A so drin steht, die ja auf Peer B kopiert wird.

Peer A-Config (Rede mit Peer B) ---> Sync / Copy ---> Peer B-Config (Rede mit Peer B)   

Diese Lösung ist also nicht ideal.
Suche nach einem Weg den Traffic intern im 10.0.0.0/24er Netz zu behalten, statt sie ins WAN zu pusten, wo sie nach meinem Empfinden nicht hin gehören  - andere Hersteller halten das genau so, da geht alles, was mit HA zu tun hat über ein Interface bzw Kabel.
 

[Patrick M. Hausen]

aber 224er Adressen landen ja per Default-Route immer am WAN Interface

Nein, tun sie nicht. Das sind Multicast-Adressen, die werden an eine Multicast-MAC-Adresse geschickt, die landen eben nicht beim Gateway. Wie kommst du darauf?

Außerdem - wenn du mit Unicast arbeiten möchstest, kannst du das natürlich tun. Der Backup-Node synchronisiert da sowieso nichts zurück, das geht alles nur in einer Richtung. Vom Master zum Backup.

Nochmal zu deiner Annahme, da ginge irgendetwas zum WAN hinaus ;-) ...

Das passiert auf dem HA-Interface bei meinem Cluster:

Code Select Expand

tcpdump -i igb1 -n -e net 224
[...]
13:11:32.540758 a0:36:9f:0c:59:f9 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 981: 10.31.0.101 > 224.0.0.240: PFSYNCv5 len 947
    insert count 3
    update compressed count 1
    eof count 1
[...]

Das ist pfsync. Die Ziel-MAC-Adresse ist 01:00:5e:00:00:f0 - das ist nicht die MAC-Adresse der Backup-Firewall sondern eine Multicast-MAC. Spielt auf dem HA-Interface aber natürlich keine Rolle, das ist ja nur ein Kabel.

Jetzt gucken wir mal auf dem WAN - bei mir vlan01:

Code Select Expand

root@opnsense1:~ # tcpdump -i vlan01 -n -e net 224
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vlan01, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:14:38.840840 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
13:14:39.843099 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
13:14:40.849956 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
13:14:41.857790 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
13:14:42.866653 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
13:14:43.871724 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
13:14:44.888311 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 49.13.251.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
[...]

Das sind CARP-Pakete. Die gehen nicht an 224.0.0.240 sondern an 224.0.0.18 - die Multicast-Adresse für CARP und VRRP.

Und auch diese gehen an eine Multicast-MAC-Adresse: 01:00:5e:00:00:12

Also nicht an den Default-Gateway!

Dieser hat in meinem Fall die MAC: f2:0b:a4:d1:20:01 - der sieht diese Pakete also nie. Die sehen nur Hosts, die bei dem entsprechenden Multicast-Protokoll aktiv "mitspielen".

Und nochmal: für CARP müssen die beiden Nodes auf jedem Interface miteinander CARP sprechen, wo eine HA/CARP-Adresse konfiguriert ist. Das wird auf jedem Interface einzeln über ein Multicast-Protokoll ausgehandelt. Und das hat nichts aber auch gar nichts mit dem pfsync zu tun, was du da siehst, das sind andere Multicast-Adressen.

Und Multicast-Pakete verlassen das lokale Interface nicht - so lange nicht IGMP und irgendwelches Multicast-Routing im Spiel ist.

Du versuchst ein nicht existentes Problem zu "lösen".

[trixter]

Hmm, mag sein dass ich hier ein theoretisches Einhorn jage.

Aber die Logs aus der Praxis sehen für mich halt so aus.

[Patrick M. Hausen]

Das CARP (224.0.0.18) das muss da hin - die beiden Firewalls unterhalten sich über die WAN Interfaces miteinander und handeln die HA-Adresse auf dem WAN Interface aus. Nichts davon landet beim Default-Gateway.

Du hast doch ein gemeinsames Netz (Switch) mit deinen beiden Firewalls und dem Router vom Provider? Wieso sollen die beiden Firewalls sich nicht miteinander per Multicast unterhalten? CARP funktioniert nunmal so.

Der Master bläst auf dem Interface raus "Ich hab Prio 0, ich diese und jene VHID". Der Backup empfängt das, denkt sich "ich hab Prio 100, der hat 0 - also ist der der Chef". Und dann aktiviert der Master die CARP IP-Adresse bei sich, weil er ja keinen Widerspruch bekommt.

Wenn du den Master abschaltest oder der absemmelt, denkt sich der Backup "ich hab Prio 100, ich hab Ewigkeiten nix mehr von jemandem mit niedrigerem Wert == höherer Prio gehört, also muss ich wohl Chef sein". Und aktiviert die Adresse bei sich.

CARP läuft auf jedem Link unabhängig und lokal auf diesem Link ohne jede Kommunikation und Austausch zwischen den beiden Knoten. Die beobachten einfach jeder für sich, was auf dem Draht abgeht, und aktivieren dann entsprechend die Adresse oder eben nicht. Das ist ein HA-Protokoll, das ist mit Absicht so primitiv wie möglich.


224.0.0.22 ist IGMP. Hast du evtl. den IGMP-Proxy aktiviert? Mach den mal aus ... hast du eine Anwendung, die das wirklich brauchen würde? Sonst mach mal ein tcpdump mit den MAC-Adressen (-e) und guck, wo das eigentlich her kommt und das da eigentlich drin steht.


Und weshalb nun da Pakete mit pfsync (224.0.0.240) auf WAN auftauchen, kann ich dir tatsächlich nicht sagen - das ist bei mir nicht der Fall. Die gehören da nicht hin.

Aber CARP und den HA-Kram bitte nicht verwechseln - all das ist völlig unabhängig voneinander, auch wenn man für einen funktionierenden HA-Cluster natürlich alles davon parallel braucht.

Was ist denn das Sync_722 für ein Interface? Nur ein Kabel zwischen den Firewalls? Oder steckt das am Ende im selben Switch wie WAN oder irgend so etwas?

[trixter]

Hi Patrick,

mein Problem: der Cluster ist produktiv und ich soll den Debuggen.
Habe mir dafür eine 2te Instanz in exakt die selben Netze gebaut - jetzt gehen die sich scheinbar gegenseitig quer.

Außerdem finde ich es komisch eine Firewall über Broadcasts auf dem WAN zu steuern - da juckt es einfach im Kopf.
Das ist dann doch anfällig für Replay-Attacken?

Gut wir müssen gleich 3 Protokolle hin bekommen, warum eigentlich? Macht es doch die Sache an sich unheimlich komplex.
Andere Hersteller können das doch auch über EIN Interface.

Also PFsync läuft auf dem WAN - warum auch immer
CARP läuft auf jedem Interface - zum glück gibt es hier Auto-Regeln
XMLRPC läuft tatsächlich auf dem angegeben Interface - vorausgesetzt man hat das Webinterface darauf laufen. Regeln bitte händisch anlegen.

Theoretisch könnte XMLRPC alle 3 Aufgaben auf einem internen Interface übernehmen, weil relativ frei ist, was in den Packeten steht.

[Patrick M. Hausen]

Habe mir dafür eine 2te Instanz in exakt die selben Netze gebaut - jetzt gehen die sich scheinbar gegenseitig quer.

Natürlich, du musst bei der Test-Instanz andere VHIDs für die CARP-Adressen verwenden, sonst sprechen alle 4 Systeme miteinander.

Die Firewalls werden auch nicht über Broadcasts "gesteuert". Zwei Router handeln eine CARP-Adresse per lokalem Multicast aus. Das macht Cisco IOS mit VRRP und/oder HSRP so, das macht Linux mit CARP so, das macht FreeBSD so ...

CARP ist im Kernel, da wird einfach eine HA-Adresse definiert und dann über Prioritäten ausgehandelt, welcher von N Nodes die jetzt aktiv setzen darf. Da gibt es keinen Daemon, kein Protokoll, keine Steuerung - da das HA ist, ist das so "dumm" wie möglich designed. Das gilt für VRRP oder HSRP aber auch, die funktionieren im Wesentlichen genauso.

Dieser Teil kümmert sich aber nur um die IP-Adresse. Der weiß nix von Diensten, nix von OPNsense, nix von Config- oder pf-Sync ... der handelt nur aus, wo die Adresse liegt, die man dann als "Cluster-Adresse" ins DNS einträgt. Wie soll er das auch sonst machen? Du ziehst bei einem von beiden Nodes nur das WAN ab - wenn die beiden über das WAN nicht miteinander sprächen, wie sollte der Backup dann merken, dass er jetzt die Adresse übernehmen sollte?

Das ist auch bei allen kommerziellen Produkten so, wenn die irgendwas mit CARP/VRRP/HSRP machen ...

Für die höher im Stack angesiedelten Dienste gibt es dann im CARP eine "Notification"-Funktion, die dann Skripte aufrufen kann, um z.B. auf einem Node den DHCPd aus- und auf dem anderen einzuschalten.

Gruß
Patrick