Hochverfügbares VPN mit OpenVPN und Keepalived

Doppelt hält besser

Virtuelle private Netze sind ein probates Mittel, um sensible Daten über öffentliche Netzwerke zu übertragen. Im Unternehmensbereich verbinden VPNs häufig unterschiedliche Standorte oder gewähren mobilen Clients Zugriff zum internen Firmennetzwerk. Dieser Artikel baut mit OpenVPN und Keepalived ein hochverfügbares Zwei-Node-Setup auf.
Die dunkle Jahreszeit ist Einbruchszeit - ein Anlass, auch die IT-Sicherheit unter die Lupe zu nehmen. In der Oktober-Ausgabe des IT-Administrator lesen Sie, ... (mehr)

Hat sich ein VPN erst einmal im Unternehmen etabliert, ist es aus dem IT-Alltag nicht mehr wegzudenken. Off-Site-Sicherungen von Daten an einen zweiten Standort, Monitoring von Server-Diensten in einem anderen Rechenzentrum oder Remote-Netzwerkzugriff sind prominente Einsatzmöglichkeiten. Alle Punkte haben gemein, dass sie für ein intaktes IT-Umfeld unverzichtbar sind. Umso wichtiger ist, die VPN-Infrastruktur von Beginn an hochverfügbar auszulegen, um später nicht sein blaues Wunder zu erleben. Bild 1 zeigt, wie ein entsprechendes Setup mit zwei Servern (Master und Backup) aufgebaut wird. Das Hauptaugenmerk liegt auf einer gemeinsamen IP-Adresse, die jeweils nur auf einem der beiden Nodes aktiv ist – die "Floating IP".

Keepalived steuert IP-Adresse

Im Grunde reicht für die Hochverfügbarkeit die Floating IP, die zwischen den beiden VPN-Severn hin- und herwandert. Fällt der Master-Node aus, übernimmt der Backup-Node seine Dienste und weist sich dessen IP-Adresse zu.

Die Verwaltung der Floating IP fällt in die Hände von Keepalived, einem einfachen Daemon, der auf beiden Nodes aktiv ist. Die Keepalived-Instanzen überwachen sich gegenseitig, indem sie VRRP-Nachrichten austauschen. VRRP – das Virtual Router Redundancy Protocol – stammt, wie der Name erahnen lässt, aus der Routing-Welt. Per Multicasts informiert der Master den Backup-Server über seinen Status. Fällt dieser Heartbeat aus, übernimmt der Backup-Server die virtuellen Adressen, da er davon ausgehen muss, dass der Master nicht mehr aktiv ist. Hochverfügbarkeit ist nicht der einzige Einsatzbereich von Keepalived, er kann auch Loadbalancing-Aufgaben übernehmen. Dann verteilt der Daemon, zum Beispiel via Round-Robin, Anfragen an hinter ihm liegende Backends.

Für die korrekte Funktionsweise von Keepalived ist es unerlässlich, dass zwischen den beiden Nodes Multicasts und VRRP als Protokoll erlaubt sind. Per IPtables wird das mit den folgenden Regeln sichergestellt:

$ iptables -I INPUT -p tcp -d 224.0.0.0/8 -j ACCEPT
$ iptables -I INPUT -p vrrp -j ACCEPT

Ob diese Regeln greifen und die VRRP-Pakete am Backup-Server angelangen, zeigt »tcpdump« :

vpn2:~$ sudo tcpdump -i enp0s9 vrrp
listening on enp0s9, link-type EN10MB (Ethernet), capture 
size 262144 bytes 
18:17:04.346331 IP 192.168.56.101 > vrrp.mcast.net: VRRPv2, 
Advertisement, vrid 167, prio 101, authtype none, intvl 1s, length 20 
18:17:05.346765 IP 192.168.56.101 > vrrp.mcast.net: VRRPv2, 
Advertisement, vrid 167, prio 101, authtype none, intvl 1s, length 20 

In der obigen Ausgabe von »tcpdump« ist klar ersichtlich, dass der Master wie gewünscht VRRP-Multicasts ausschickt, die beim Backup-Server ankommen. Das Netzwerk-Setup ist korrekt für die Kommunikation der Keepalived-Instanzen eingerichtet. Ist das nicht der Fall, ist in der Regel die Floating IP auf beiden Nodes aktiv – Master und Backup befinden sich in einer Split-Brain-Situation.

Bild 1: Zusammenspiel zwischen OpenVPN und Keepalived.

Installation und Setup

Keepalived ist in den Ubuntu-Repositories als Package vorhanden, ein apt-get-Aufruf installiert die Software nach:

vpn1:~$ sudo apt-get install keepalived 
vpn1:~$ sudo ls /etc/keepalived/ 

Das ls-Kommando in "/etc/keepalived" zeigt, dass standardmäßig keine virtuellen IP-Adressen eingerichtet sind. Für das Setup muss sich der Benutzer folgende Dinge zurechtlegen:

- Das Netzwerk-Interface, mit dem Keepalived arbeiten soll, und die zugehörige IP-Adresse.

- Eine Router-ID, die für Master und Backup eindeutig ist.

- Den Pfad zu einem Failover-Skript, das OpenVPN stoppt und startet.

- Falls erforderlich Netzwerk-Routen, die mit der IP-Adresse umgezogen werden.

In Listing 1 werden zumindest die ersten drei Punkte definiert. Die Routen entfallen, da keine erforderlich sind. Ansonsten können Sie auf die Option "virtual_routes" zurückgreifen.

Listing 1: Keepalived-Konfiguration

 vpn1:~$ sudo vi /etc/keepalived/keepalived.conf 
 # Configuration file for keepalived 
 global_defs { 
         router_id vpn.example.com 
 } 
 vrrp_script chk_service { 
       script "killall -0 openvpn" 
       interval 2 
         fall 2 
         rise 2 
         weight 2 
 } 
 vrrp_instance VI_1 { 
         interface enp0s9 
         state MASTER 
       priority 101 
       virtual_router_id 167 
       advert_int 1 
       notify /etc/keepalived/keepalived_failover.sh 
       virtual_ipaddress {    192.168.56.201/24 
         } 
       track_script { 
              chk_service 
       } 
 } 

Die Keepalived-Konfiguration ist weitgehend selbsterklärend und bis auf wenige Ausnahmen für Master und Back­up gleich. Die Optionen "state" und "priority" unterscheiden den Backup-Node vom Master, er verwendet "state BACKUP" und "priority 100".

Besondere Aufmerksamkeit gilt den Parametern "chk_service" und "notify" , die die Verbindung zwischen Keepalived und OpenVPN herstellen. Per "chk_service" erhält jene Instanz zwei zusätzliche Prioritätspunkte ("weight 2"), auf denen der OpenVPN-Prozess läuft ("killall -0 openvpn"). Das Failover-Skript "keepalived_failover.sh" kommt bei State-Transfers von Keepalived zum Einsatz (Listing 2). Wechselt zum Beispiel der Master in den Backup-Modus oder in einen undefinierten Fault-State, wird per Skript der VPN-Dienst gestoppt. Beide Maßnahmen, sowohl "chk_service" als auch "notify", stellen sicher, dass OpenVPN nur auf dem Master-Node aktiv ist.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023