OpenVPN

Der Parameter »dev« definiert, dass OpenVPN beim Start ein Tun-Interface erstellt. Das führt zu einem VPN auf OSI-Schicht 3, bei dem die VPN-Zugänge als Router fungieren. Möglich wäre auch eine Netzkopplung auf Schicht 2, die wie eine Bridge arbeitet. Diese Technik ist allerdings eher für Sonderfälle sinnvoll. Die »ifconfig«-Anweisung in Zeile 2 legt die lokale und die entfernte IP-Adresse fest. In Zeile 4 beschreibt »route« den Weg zum Netzwerk in der Außenstelle – dieser Parameter sorgt dafür, dass die Pakete für das Netz der Außenstelle 10.128.0.0/24 über die VPN-Gegenstelle 172.16.0.2 und damit durch den Tunnel laufen.

Zu welchen IP-Adressen sich der VPN-Client tatsächlich verbindet, wird mit dem Parameter »remote« konfiguriert. Da das Beispiel beide VPN-Tunnel über das Internet abwickelt, hat der Client auch beide Ziele eingetragen: 62.91.24.1 und 62.91.24.2. Beim Start der Ressource versucht OpenVPN, sich zuerst mit 62.91.24.1 zu verbinden, und wenn das scheitert, probiert es 62.91.24.2.

Damit sich der VPN-Tunnel beim Abbruch der Verbindung nicht selbstständig schließt und somit der Heartbeat-Kontrolle zuvorkommt, muss »persist-tun« in der Konfiguration enthalten sein (Zeile 9). Abschließend gibt Zeile 11 noch per »secret«-Eintrag an, in welcher Datei sich der Pre-Shared Key befindet. Der Key muss auf allen beteiligten Knoten identisch sein. Einen neuen Schlüssel erzeugt folgendes OpenVPN-eigene Kommando:

openvpn --genkey --secret vpn.key

Nach der Konfiguration beider Komponenten ist noch zu beachten, dass OpenVPN nur durch Heartbeat gestartet oder gestoppt wird, sprich: OpenVPN darf in keinem regulären Runlevel des Systems eingetragen sein.

Sessions bleiben erhalten

Solange alle Leitungen und Cluster-Knoten verfügbar sind, verbinden sich die beiden primären Nodes direkt miteinander. Ist eine Leitung gestört oder fällt ein Knoten aus, so übernimmt der andere Node. Da die Verbindungen zwischen Hauptstelle und Nebenstelle über

OpenVPN getunnelt werden und innerhalb des virtuellen Netzes sich weder Adressen noch Ports ändern, bleiben alle Netzwerk-Sessions zwischen den Standorten erhalten. Der Wechsel der Knoten oder des Leitungsweges ist für den Client unsichtbar, bestenfalls ein kurzes Stottern bleibt bemerkbar. Testen lässt sich dieser Aufbau sehr einfach: Den Netzwerkstecker ziehen simuliert praxisnah einen Ausfall einer Leitung. Wer keine Leitungen kappen will, kann den Cluster-Schwenk auch manuell per Heartbeat-Skript auslösen. Hierzu hält Heartbeat die beiden Tools »hb_takeover« und »hb_standby« bereit, die standardmäßig in »/usr/lib/heartbeat« installiert sind. Die Skripts zwingen den Knoten, auf dem sie der Admin aufgerufen hat, in den Status »Takeover« (übernimmt die Ressource) oder »Standy« (gibt die Ressource auf). Dabei ist ein Hin- und Herschwenken jederzeit möglich. Manuelle oder automatische Ressourcenübernahmen protokolliert die Cluster-Software per Syslog. Dort steht nicht nur dass und wann die Ressource gewandert ist, sondern auch weshalb. Ob das Routing richtig funktioniert hat und die Pakete tatsächlich durch den OpenVPN-Tunnel laufen, lässt sich per Traceroute prüfen.

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