Jan 25, 2024, updated at 13:46:06 (UTC)

1053

Keepalived mit IPFire

Hallo zusammen,

ich plane derzeit folgendes Netzwerksetup.

Ich würd gerne den Keepalived so Konfigurieren, dass bei Ausfall des IPFire-01 der ganze Datenvekehr über IPFire-02 läuft.

Standartmäßig soll der Datenvekehr nur über IPFire-01 laufen.

folgendes habe ich bisher dazu gefunden:

https://www.ipfire.org/docs/addons/keepalived

Wie muss ich den Keepalived dafür konfigurieren?

Viele Grüße

Jannik

Please also mark the comments that contributed to the solution of the article

Content-Key: 62060454358

Url: https://administrator.de/contentid/62060454358

Printed on: April 27, 2024 at 16:04 o'clock

17 Comments

Latest comment

Hallo,
der Abschnitt Use Case VRRP im oben genannten Link https://www.ipfire.org/docs/addons/keepalived macht das was du willst.

Wie muss ich den Keepalived dafür konfigurieren?

Steht ja auf der oben genannten Seite sehr detailliert beschrieben, wo liegt dein Problem?

Gruß abm

Mir ist die Zuordnung zu den IP Adressen nicht ganz klar muss die Gateway IP des Lan = die Virtual IP sein?
und wie ist das mit der IP des Grünen Interface muss es beides die 1.1 sein?

Zitat von @Jannik2018:

Mir ist die Zuordnung zu den IP Adressen nicht ganz klar muss die Gateway IP des Lan = die Virtual IP sein?

Ja, die Virtual IP ist bei beiden Routern gleich diese ist immer das Gateway für die Clients!
Bei einem Failover meldet sich dann einfach nur die jeweils noch aktive IPFire per ARP auf dieser IP. Im Normalzustand meldet sich nur der Master per ARP, auf dieser IP nur wenn der down ist (im Failover Fall), übernimmt der Backup-Router und meldet sicb dann per ARP bei Anfragen an die Virtual IP.
Standard VRRP Procedure

und wie ist das mit der IP des Grünen Interface muss es beides die 1.1 sein?

Jede IPFire bekommt als erstes eine physische IP aus dem Subnetz, also bspw. 192.168.1.2 für die erste und 192.168.1.3 für die zweite, für die Virtual VRRP IP kannst du dann bspw. die 192.168.1.1 nehmen, diese muss auch auf beiden IPFires gleich sein, wichtig ist auch das diese IP noch nicht im Netz belegt ist. Standard-GW für die Clients ist dann immer die VirtualIP.

Auch mal was zu den Grundlagen lesen
https://de.m.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol

An dieser Stelle setzt das VRRP an. Mehrere physische Router werden zu einer logischen Gruppe zusammengefasst, die sich im Netzwerk nun als ein logischer virtueller Router präsentiert.

Hierzu wird dem logischen Router eine virtuelle IP-Adresse und eine virtuelle MAC-Adresse zugeordnet. Einer der Router innerhalb der Gruppe wird als der virtuelle Master-Router definiert. Dieser bindet daraufhin die virtuelle MAC- und die virtuelle IP-Adresse an sein Netzwerkinterface und informiert die anderen Router der Gruppe, die als virtuelle Backup-Router agieren.

Fällt der Master-Router aus, werden die virtuelle IP-Adresse und die virtuelle MAC-Adresse innerhalb von (Milli)Sekunden auf einen der Backup-Router übertragen, der damit zum neuen Master-Router wird.[3] Sowohl die MAC- als auch die IP-Adresse werden transferiert, damit die betroffenen Hosts nicht ihren ARP-Cache aktualisieren müssen. Die Folgen des Ausfalls des ersten Routers auf der Route können somit reduziert werden. Dieses Redundanzprinzip wird Hot Standby genannt.

könnte ich das ganze auch auf dem red interface bauen sodass immer die 192.168.40.112 zwischen den beiden wechselt?

Zitat von @Jannik2018:

könnte ich das ganze auch auf dem red interface bauen sodass immer die 192.168.40.112 zwischen den beiden wechselt?

Klar. VRRP lässt sich für mehrere Interface-Gruppen konfigurieren

Zitat von @abamakabra:

Zitat von @Jannik2018:

könnte ich das ganze auch auf dem red interface bauen sodass immer die 192.168.40.112 zwischen den beiden wechselt?

Klar. VRRP lässt sich für mehrere Interface-Gruppen konfigurieren

Das scheint nicht ganz zu klappen er will nämlich die Virtual Ip auf Red nicht setzen.

Tja da gehört natürlich mehr dazu ... Angefangen von Firewall Regeln für den VRRP Verkehr zur Abstimmung der beiden IPFires auf dem roten Interface etc.!!
Verstehe erst mal das VRRP Prinzip und die Kommunikation dahinter dann weißt du auch was an Konfiguration nötig ist. Einen Schritt nach dem anderen. Ich fliege ja auch nicht gleich einen Jumbo nach dem PPL.

Zitat von @abamakabra:

Tja da gehört natürlich mehr dazu ... Angefangen von Firewall Regeln für den VRRP Verkehr auf dem roten Interface etc.!!
Verstehe erst mal das VRRP Prinzip und die Kommunikation dahinter dann weißt du auch was an Konfiguration nötig ist. Einen Schritt nach dem anderen.

Firewallregel ist auch erstellt

Und du meinst jetzt ich soll mir deine Config aus den Fingern saugen? Freitagnachmittag vor Feierabend Glaskugel Raten ... 🙃
Meine Vermutung die VRID wurde nicht korrekt differenziert angepasst damit zwei Instanzen laufen, wobei wir mal wieder bei den Grundlagen wären, die ja offensichtlich fehlen, Trial&Error by it's best.

Verstehe erst mal das VRRP Prinzip

Guckst du auch hier:
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
VRRP mit Mikrotik
Im Zweifel mit tcpdump mal checken ob die VRRP Frames beidseitig überhaupt ankommen.

Servus Jannik2018,
der Grund warum das bei der IPFire auf dem RED-Interface so nicht läuft ist das die IPFire dort per Default kein Multicast aktiviert hat..

/etc/init.d/networking/red.up/10-multicast

Multicast auf dem red0 Interface manuell aktivieren kannst du für einen Test mittels folgenden Befehls

ifconfig red0 multicast

Du musst also in Keepalived statt einer Multicast-Konfiguration einen unicast peer hinterlegen oder das obige init Skript anpassen/auskommentieren damit Multicast auch auf dem red0 Interface nach einem Reboot aktiviert ist.

Beispiel für dein Szenario mit Multicast auf green0 und Unicast auf red0:

IPFire-01

# VRRP Instance on LAN
vrrp_instance VI_LAN {
  state MASTER
  interface green0
  virtual_router_id 10
  priority 150
  advert_int 1
  authentication {
      auth_type AH
      auth_pass vrrp4lan
  }
  virtual_ipaddress {
      192.168.1.1/24 brd 192.168.1.255 dev green0
  }
}

# VRRP Instance on WAN
vrrp_instance VI_WAN {
  state MASTER
  interface red0
  unicast_peer {
     192.168.40.111
  }
  virtual_router_id 20
  priority 150
  advert_int 1
  authentication {
      auth_type AH
      auth_pass vrrp4wan
  }
  virtual_ipaddress {
      192.168.40.112/24 brd 192.168.40.255 dev red0
  }
}

IPFire-02

# VRRP Instance on LAN
vrrp_instance VI_LAN {
  state BACKUP
  interface green0
  virtual_router_id 10
  priority 100
  advert_int 1
  authentication {
      auth_type AH
      auth_pass vrrp4lan
  }
  virtual_ipaddress {
      192.168.1.1/24 brd 192.168.1.255 dev green0
  }
}

# VRRP Instance on WAN
vrrp_instance VI_WAN {
  state BACKUP
  interface red0
  unicast_peer {
     192.168.40.110
  }
  virtual_router_id 20
  priority 100
  advert_int 1
  authentication {
      auth_type AH
      auth_pass vrrp4wan
  }
  virtual_ipaddress {
      192.168.40.112/24 brd 192.168.40.255 dev red0
  }
}

Firewall für das jeweilige Gegenüber auf dem red0 Interface nicht vergessen.

Grüße Uwe

vielen Dank für die wirklich gute Beschreibung

als Firewall Regel für das gegenüber so?

als Firewall Regel für das gegenüber so?

Ja. Die Quelladresse könntest du noch zusätzlich mit in die Regel rein nehmen.

komischerweise habe ich noch auf beiden IPFire die 192.168.40.112 auch nach einem Neustart

Wenn es das denn nun war:
How can I mark a post as solved?

Das Problem ist leider noch nicht behoben, daher lasse ich das Thema noch offen

German Question Networks