StandBy-Backup des zentralen Routers mit VRRP

Da es aufgrund meiner Spielereien immer wieder vorkommt, dass bei mir zu Hause mal „gar nichts“ mehr geht, ziehe ich mir des öfteren den Unmut meiner Familie auf sich. Das Wichtigste ist, dass in solchen „Katastrophen-Fällen“ das Internet noch funktioniert 🙂 Mit etwas Recherche habe ich mit Hilfe des Virtual Router Redundancy Protocol (VRRP) und ohne neue Hardware einen automatischen Fallback-Router aufgebaut, der automatisch einspringt, wenn mein zentraler Vyos-Router (läuft auf ESX) mal gerade nicht verfügbar ist.

Idee

Neben meinem zentralen Router läuft bei mit u.a. ein OpenWrt-Router („archerc7“), der v.a. als Access-Point dient. Dank OpenWrt hat dieser aber auch einen manage-baren Switch und ist daher sehr flexibel einsetzbar. Die Idee ist nun, diesen als Hot-Standby-Router ins Internet zu betreiben: Ich konfiguriere mir diesen also als zweiten Router zwischen internem und externem Netz (Internet).

Dann erstelle ich mit Hilfe von VRRP neue neue virtuelle IP .254. VRRP handelt zwischen den beiden Routern aus, welcher von beiden diese IP gerade „besitzt“. Diese IP verwende ich nun als Default-Router und Nameserver für Rechner im internen Netz. Auf diese Weise gibt es immer eine funktionierende Verbindung ins Internet.

Netz-Skizze mit VRRP

Da mein Vyos noch deutlich mehr „kann“, habe ich das ganze so eingestellt, dass sobald dieser Router arbeitet, er auch zuständig ist und die IP vom anderen „übernimmt“ (höhere Prio).

Config Vyos

Von hier habe ich mir das Prinzip geholt. Bei mir sieht das dann so aus:

    ethernet eth0 {
        ...
        vif 100 {
            description "lokales, internes Netz VLAN"
            address 192.168.40.1/24
            firewall {
                ...
            }
            vrrp {
               vrrp-group 10 {
                    authentication {
                        password xxx
                        type plaintext-password
                    }
                    hello-source-address 192.168.40.1
                    preempt true
                    priority 150
                    virtual-address 192.168.40.254/24
                }
            }
        }
        ...
    }

preempt bewirkt, dass diese Instanz anderen die Hoheit „entreißen“ soll.

Config OpenWrt

Diese Seite beschreibt, was unter OpenWrt zu tun ist. Sie hat zwar ein paar Fehler, hilft aber trotzdem. Hier meine darauf basierende Lösung:

opkg update und opkg install keepalived.

In /etc/keepalived/keepalived.conf:

vrrp_instance I1 {        
  state backup           
  interface br-lan
  virtual_router_id 10
  priority 99         
  advert_int 1        
  virtual_ipaddress { 
    192.168.40.254/24 
  }                  
  authentication {   
    auth_type PASS   
    auth_pass xxx
  }                   
  nopreempt           
}

In /etc/sysupgrade.conf hinzufügen:
```
/etc/keepalived/
/etc/conntrackd/
```
(conntrack nur vorsorglich, falls ich es auch mal konfiguriere.)

Zum Laufen bringen

Das Ganze lief erstaunlich problemlos fast auf Anhieb. Nur mit arp hatte ich eine Zeitlang Probleme, die ich mit tcpdump aufgespürt habe:

sudo tcpdump -nnq -i eth0.100 -e arp

Danach nur noch dhcp umstellen, sodass die .254 als Default-Gateway und als Nameserver verwendet wird. Und manche Server mit fix eingestellten Werten per Hand umkonfigurieren.

Einige Experimente bestätigen die Funktionsweise

Im Syslog sieht man, wie die „Verantwortung“ hin- und zurück-übertragen wird, wenn z.B. der vyos-Router mal neugestartet wird:

...
Jan 22 09:35:55 vyoshost Keepalived: Terminating on signal
Jan 22 09:35:55 vyoshost Keepalived: Stopping Keepalived v1.2.2 (12/24,2014)
Jan 22 09:35:55 vyoshost Keepalived_vrrp: Terminating VRRP child process on signal
Jan 22 09:35:55 vyoshost Keepalived_vrrp: VRRP_Instance(vyatta-eth0.100-10) sending 0 priority
Jan 22 09:35:55 vyoshost Keepalived_vrrp: VRRP_Instance(vyatta-eth0.100-10) removing protocol VIPs.
...
Jan 22 09:35:56 archerc7.steinkopf.net Keepalived_vrrp[12246]: VRRP_Instance(I1) Transition to MASTER STATE
Jan 22 09:35:57 archerc7.steinkopf.net Keepalived_vrrp[12246]: VRRP_Instance(I1) Entering MASTER STATE
...
Jan 22 09:36:50 archerc7.steinkopf.net Keepalived_vrrp[12246]: VRRP_Instance(I1) Received higher prio advert
Jan 22 09:36:50 archerc7.steinkopf.net Keepalived_vrrp[12246]: VRRP_Instance(I1) Entering BACKUP STATE
...

Und traceroute zeigt die beiden Routen:

„Normalfall“ via vyos:

# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  vyos.steinkopf.net (192.168.40.1)  0.173 ms  0.149 ms  0.166 ms
 2  tun-transfer.steinkopf.net (192.168.179.254)  22.446 ms  22.533 ms  22.823 ms
 3  v412.ce01.fra-10.de.leaseweb.net (178.162.193.124)  23.228 ms  23.030 ms v412.ce02.fra-10.de.leaseweb.net (178.162.193.125)  23.721 ms
 ...
12  * google-public-dns-a.google.com (8.8.8.8)  32.829 ms *

(NB. Hier sieht man auch, dass mein über vyos einen VPN-Tunnel routet, aber das ist eine andere Geschichte…)

„Backup“ via OpenWrt:

# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  archerc7.steinkopf.net (192.168.40.2)  0.323 ms  0.398 ms  0.462 ms
 2  fritz.box (192.168.33.1)  1.339 ms  1.379 ms  1.767 ms
 ...
 8  google-public-dns-a.google.com (8.8.8.8)  24.724 ms  17.529 ms  17.642 ms

nerdblog