Software-VPN als Audio-/Video-Killer

Der Pandemie-Knüller: Virtual Private Network

Covid-19 hat plötzlich allein in Deutschland Millionen von Arbeitsplätzen in die privaten Haushalte verlegt. Mittlerweile verbringen zwar wieder mehr Beschäftigte einen immer größeren Anteil ihrer Arbeitszeit in den Büroräumen ihrer Arbeitgeber. Jedoch ist davon auszugehen, dass auch auf Dauer die Arbeit von zuhause aus um Größenordnungen häufiger praktiziert wird als vor März 2020.

Das Hauptwerkzeug für den Fernzugriff auf IT-Ressourcen der Organisation ist und bleibt das Virtual Private Network (VPN). Cloud Computing wird auch genutzt, jedoch nicht in dem Maße, dass der VPN-Tunnel zu den IT-Räumen des Arbeitgebers seine zentrale Rolle einbüßt.

Vor zwei Jahren mussten buchstäblich über Nacht bereits eingeführte, jedoch auf eine relativ kleine Anzahl von mobilen und Heimarbeitsplätzen ausgerichtete VPN-Lösungen ein Vielfaches an Last bewältigen. Dabei stießen einige Lösungen an die Grenzen ihrer Leistungsfähigkeit.

VPN in Software oder Hardware?

Software-Defined (SD) ist ein Modeattribut. Es ist verständlicherweise attraktiv, auf Basis einer Standard-x86-Hardware Funktionen zu nutzen, für die bis vor wenigen Jahren teure proprietäre Hardware beschafft werden musste. VPN-Gateways auf x86-Basis gibt es aber nicht erst seit der Verbreitung des ungefähr 10 Jahre alten SD-Labels, sondern seit über 25 Jahren. Mit OpenVPN kann sogar eine kostenlose VPN-Software genutzt werden. Alles, was an zentraler Stelle dafür gebraucht wird, ist ein x86-Rechner und natürlich ein Internetanschluss mit fester IP-Adresse und genügend Bitrate für den Zugriff der zu erwartenden Anzahl von Telearbeitsplätzen.

Der zentrale Internetanschluss ist aber nicht der einzige denkbare Flaschenhals für den Fernzugriff. Auch das VPN-Gateway kann zu einem Engpass werden. Es ist zu bedenken, dass Standard-x86-Hardware nicht auf die Funktion als VPN-Gateway optimiert ist. Verarbeitungsintensive Aufgaben wie Verschlüsselung werden in einem Software-Gateway eben in Software abgewickelt. Das kann insbesondere bei hoch skalierten Lösungen zum Problem werden.

Praxis bestätigt Theorie

Neulich bekam ich mit, dass die Praxis wieder einmal die Theorie bestätigt.

Zunächst einmal eine allgemeine Regel bei der Fehlersuche: Es gibt Situationen, in denen die messtechnische Analyse von IT-Problemen schwerfällt. Das gilt insbesondere dann, wenn die Symptombeschreibung seitens der Benutzer der Hauptanlass der Fehlersuche ist und wenn das Problem nicht jederzeit nachgestellt werden kann. Ersteres ist bei Nutzung von Audio- und Videokonferenzen oft der Fall, Letzteres bei Untersuchungen in einer Laborumgebung sowie in Fällen, in denen das Problem nur zeitweilig auftritt.

Ist die messtechnische Analyse nicht möglich, bleibt noch die indizienbasierende Fehlersuche. Sie kann schnell um Erfolg führen. Wenn zum Beispiel

• alle – und nicht nur wenige – Personen darüber klagen, dass täglich zu bestimmten Uhrzeiten die Audio-/Video-Qualität bei der Nutzung einer Kommunikationslösung schlecht ist, und
• diese bestimmten Uhrzeiten mit Zeiten der höchsten Anzahl aufgebauter VPN-Verbindungen korrelieren, und
• die Probleme ausschließlich dann Personen betreffen, die über VPN auf die Kommunikationslösung zugreifen, und
• gleichzeitig zu Videokonferenzproblemen auch die IP-Telefonie leidet, wenn sie über dieselben VPN-Gateway genutzt wird,

dann sind folgende Schlüsse erlaubt:

• Der zentrale VPN-Gateway kann als Ursache des Problems eingegrenzt werden.
• Es handelt sich nicht um ein lastabhängiges Problem.

Nichtsdestotrotz können die obigen Schlüsse durch Einrichtung von Split-Tunnels auf einigen Clients überprüft werden. Und hier kommen wir nach messtechnischer Analyse und indizienbasierender Analyse zum dritten Hauptwerkzeug beim Troubleshooting: der Substitutionsmethode. Wenn ein System nicht wie gewünscht funktioniert, ersetzt man eines seiner Komponenten. Wenn damit das Problem behoben wird, ist die ausgetauschte Komponente als Problemursache lokalisiert.

In unserem Fall bedeutet die Substitutionsmethode: Auf einigen Clients wird eine IP-Route in Richtung der öffentlichen IP-Adressen, über die Videokonferenzen aufgebaut werden können, eingerichtet. Hiermit werden die Voraussetzungen geschaffen, dass diese Clients wie externe Clients über eine reine Internet-Strecke ohne VPN an Videokonferenzen teilnehmen können.

Abhilfe

Im oben beschriebenen Fall sind folgende Abhilfen prinzipiell möglich:

• Hardware-Aufrüstung der VPN-Gateways: Dafür muss man die Software-Konfiguration nicht ändern – ein Vorteil. Aber möglicherweise verschiebt man das Problem in eine nahe Zukunft, wenn wieder steigende Last die Gateways überfordert.
• Hardware- statt Software-VPN-Gateway: Statt einer herkömmlichen x86-Hardware kann Hardware eingesetzt werden, die als VPN-Gateway optimiert ist. Einige Hersteller wie Fortinet setzen zum Beispiel eigens entwickelte Chips dafür ein. Aber solche Hardware kann teurer als x86-Hardware sein und insbesondere bei den im Geleit dieser Ausgabe erwähnten Lieferengpässen längere Lieferzeiten aufweisen.
• Nutzung einer Kommunikationslösung, die auf Internet-Basis am VPN vorbei erreichbar ist. Diese Lösung entspricht Best Practice, erfordert aber die größte Änderung gegenüber einer OnPrem-Kommunikationslösung, auf die traditionell per VPN zugegriffen wird.