===Analyse der Probleme mit dem RUB-VPN-Dienst vom 05.03.2021===

== Die Situation: ==
Gegen 10:00 Uhr brachen viele VPN-Verbindungen ab. Dieses Vorkommnis wiederholte sich nach etwa 40 Minuten erneut und ab ca. 11:00 Uhr wurden die Abstände dieser Abbrüche immer kürzer. Bis ca. 13:30 Uhr brachen die Verbindungen teilweise alle 10 Minuten ab (siehe auch [[https://noc.rub.de/cgi-bin/status/show?time=2021-03-05_14:10:39|Statushinweis]])

== Die Fehlersuche: ==
Eine Analyse der VPN-Logfiles zeigte, dass zu den Zeitpunkten, an denen viele Verbindungen abbrachen, wenig bis keine Aktivität in den Logfiles zu sehen war.
Auffällig war, dass sich diese Lücken immer direkt vor einer erfolgreichen Authentifizierung einer neuen VPN-Verbindung befanden. Parallel fanden sich auch erheblich mehr Anmeldefehler als normal in den Logfiles des RADIUS-Dienstes ((Der RADIUS-Dienst koordiniert die Anmeldung im eduroam und an den HIRN-Ports. Beide Dienste nutzen den zentralen LDAP-Service zur Authentifizierung der Benutzer.)).

Gemäß Konfiguration sollte der Timeout bei der Authentifizierung am VPN, genau wie beim RADIUS-Dienst 5 Sekunden sein. Die Logfiles zeigten allerdings bei den größeren Verbindungsabbrüchen, dass die Authentifzierung teilweise deutlich länger als 60 Sekunden benötigte. Dieser Effekt ist beim VPN-Dienst insofern problematisch, weil dieser "Single-Threaded" arbeitet, d.h. Verzögerungen bei einzelnen Aufgaben beeinträchtigen direkt alle Aufgaben eines VPN-Knotens.
Dauert eine Authentifizierung eine Sekunde, werden in dieser einen Sekunde keine Datenpakete anderer VPN-Verbindungen verarbeitet. Durch die massiven Verzögerungen kamen dann auch die Keep-Alive-Pakete bestehender Verbindungen teilweise zu spät am VPN-Knoten an (bzw. wurden verworfen), so dass dieser die Verbindungen abbrach. 

== Die Lösung: ==
Damit die Authentifizierung bestehende Verbindungen so wenig wie möglich beeinträchtigt, haben wir den Authentifizierungsprozess dahingehend geändert, dass dieser aktuell nach spätestens 5 Sekunden ((Je nach Ausprägung des Fehlerbildes wird dieser Wert noch weiter reduziert um die Verbindungsqualität zu verbessern ohne zu viele Anmeldefehler zu produzieren.)) mit einer Fehlermeldung abgebrochen wird ((Der konfigurierbare Timeout bezieht sich offensichtlich nur auf den initialen Verbindungsaufbau zum zentralen Authentifizierungsdienst.)). Weiterhin wird im Prozess bzw. beim Abbruch protokolliert, in welcher Phase ((Der Authentifizierungsprozess umfasst mehrere Phasen: Benutzer finden, Benutzer authentifizieren, Konfiguration zusammenstellen und Konfiguration an den Klienten übermitteln.)) sich der Prozess beim Abbruch befand. Mit diesen Daten konnte unsere Hypothese relativ schnell verifiziert werden.

Aus diesen Fehlermeldungsdaten werden jetzt Statistiken erstellt und an die Kollegen der zentralen Authentifzierungsdienste weitergeleitet.