Corrections

This commit is contained in:
Jan Philipp Timme 2018-11-06 14:38:52 +01:00
parent dbaf81eeac
commit 4ad18d2242
1 changed files with 15 additions and 14 deletions

View File

@ -786,7 +786,7 @@ Die Konfiguration des Betriebssystems erfolgt dabei nach den Vorgaben des IT-Tea
\paragraph{Netzwerkkonfiguration:}
Da der OpenVPN-Dienst aus dem Internet heraus erreichbar sein soll, wird der Server an das DMZ-Netz angeschlossen.
Das IT-Team hat dafür insgesamt vier IPv4- und IPv6-Adressen vergeben, um den Server und den darauf existierenden Dienst logisch zu trennen.
Das IT-Team hat dafür insgesamt vier IPv4- und IPv6-Adressen vergeben, um den Server, und den darauf existierenden Dienst, logisch zu trennen.
Über die vergebenen IPv4- und IPv6-Hostadressen kann der physische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen.
Über ein weiteres Paar von IP-Dienstadressen wird der eigentliche OpenVPN-Dienst zur Verfügung gestellt.
@ -796,7 +796,7 @@ Für IPv6 wurde das Netz \texttt{2001:638:614:1750::/64} vergeben, welches durch
Damit VPN-Clients über IPv4 mit dem Abteilungsnetz kommunizieren können, wird der private IPv4-Adressbereich für die VPN-Clients durch den VPN-Server via \textit{Network Address Translation} (NAT) auf die IPv4-Dienstadresse übersetzt.
\paragraph{Lokale Firewall:}
In Absprache mit dem Erstprüfer dieser Arbeit wurde die folgende Firewall-Richtlinie für den VPN-Server geplant und wird unter Nutzung von \texttt{iptables} umgesetzt.
In Absprache mit dem Erstprüfer dieser Arbeit wurde die folgende Firewall-Richtlinie für den VPN-Server geplant, und wird unter Nutzung von \texttt{iptables} umgesetzt.
Diese lokale Richtlinie wird durch die Firewall der Abteilung Informatik ergänzt.
Zuerst werden allgemeine Regeln definiert:
@ -830,7 +830,7 @@ proto udp6
multihome
\end{lstlisting}
OpenVPN beantwortet damit Anfragen für alle auf dem Server konfigurierten IP-Adressen.
Da auf dem Server neben den Dienstadressen auch die Hostadressen existieren, wird OpenVPN mit \texttt{multihome} angewiesen, eingehende Pakete mit der IP-Adresse zu beantworten, an die diese Pakete gerichtet waren.
Da auf dem Server neben den Dienstadressen auch die Hostadressen existieren, wird OpenVPN mit \texttt{multihome} angewiesen, eingehende Pakete mit der IP-Adresse als Absender zu beantworten, an die diese Pakete gerichtet waren.
In der \textbf{Clientkonfiguration} wird OpenVPN mit \texttt{nobind} angewiesen, den Clientsocket nicht an eine lokale Adresse zu binden. Die Angaben \texttt{port} und \texttt{proto} legen fest, wie der VPN-Server zu erreichen ist.
Über \texttt{remote} wird dann der zu verwendende VPN-Server explizit genannt.
@ -850,7 +850,7 @@ dev tun
\paragraph{IP-Adressen im VPN-Tunnel:}
Die vom IT-Team vergebenen IP-Adressbereiche für VPN-Clients werden durch den OpenVPN-Server an die Clients vergeben.
Für das vergebene IPv4-Netz wurde berücksichtigt, dass bis zu 500 VPN-Clients mit IP-Adressen versorgt werden können, indem ein \texttt{/16}-Block vergeben wurde.
Für das vergebene IPv4-Netz wurde berücksichtigt, dass 50-500 VPN-Clients problemlos mit IP-Adressen versorgt werden können, indem ein \texttt{/16}-Block vergeben wurde.
In der Konfiguration des Clients sind keine Anweisungen notwendig.
Die \textbf{Serverkonfiguration} enthält diese Anweisungen:
\begin{lstlisting}
@ -894,14 +894,15 @@ push "route-ipv6 2001:638:614:1743::/64 2001:638:614:1750::1" # Cluster
push "route-ipv6 2001:638:614:1744::/64 2001:638:614:1750::1" # experimental ipv6 network
\end{lstlisting}
Da der Platzhalter \texttt{vpn\_gateway} für IPv6-Routen leider nicht funktioniert, muss hier die IPv6-Adresse des VPN-Servers im VPN direkt als Ziel der Route angegeben werden.
Aufgrund dieser einfachen Konfiguration besteht jederzeit die Möglichkeit der Anpassung und Erweiterbarkeit.
\paragraph{Zertifikatgestützte Authentisierung:}
Um die in Kapitel~\ref{sct:user_concept} beschriebene Zertifizierungsstelle zur Benutzerauthentisierung zu verwenden und die VPN-Kommunikation nach Anforderung~\ref{req:traffic} aus Kapitel~\ref{par:requirements} abzusichern, wird OpenVPN im TLS-Modus betrieben.
Um die in Kapitel~\ref{sct:user_concept} beschriebene Zertifizierungsstelle zur Benutzerauthentisierung zu verwenden, und die VPN-Kommunikation nach Anforderung~\ref{req:traffic} aus Kapitel~\ref{par:requirements} abzusichern, wird OpenVPN im TLS-Modus betrieben.
In der \textbf{Clientkonfiguration} wird dafür der Parameter \texttt{tls-client} gesetzt, in der \textbf{Serverkonfiguration} wird analog dazu der Parameter \texttt{tls-server} verwendet.
Anschließend werden in der \textbf{Client- und Serverkonfiguration} über die Parameter \texttt{ca}, \texttt{cert} und \texttt{key} Dateipfade konfiguriert, unter denen das Wurzelzertifikat, das Client- beziehungsweise Serverzertifikat und der dazugehörige private Schlüssel abgelegt sind.
In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter denen die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch und die aktuelle Kopie der von der CA herausgegebenen CRL abgespeichert sind.
In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter denen die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch, und die aktuelle Kopie der von der CA herausgegebenen CRL, abgespeichert sind.
\begin{lstlisting}
ca inform/ca.crt
cert inform/aither.inform.hs-hannover.de.crt
@ -910,7 +911,7 @@ dh inform/dh.pem
crl-verify inform/crl.pem
\end{lstlisting}
Um zu unterbinden, dass Clientzertifikate zum Betrieb eines OpenVPN-Servers verwendet werden, wird mit dem Parameter \texttt{remote-cert-tls} in der \textbf{Clientkonfiguration} angegeben, dass von der Gegenseite ein Zertifikat mit \enquote{Serverrolle} präsentiert wird:
Um zu unterbinden, dass Clientzertifikate zum Betrieb eines OpenVPN-Servers verwendet werden, wird mit dem Parameter \texttt{remote-cert-tls} in der \textbf{Clientkonfiguration} angegeben, dass von der Gegenseite ein Zertifikat mit \enquote{Serverrolle} präsentiert werden muss:
\begin{lstlisting}
remote-cert-tls server
\end{lstlisting}
@ -920,7 +921,7 @@ remote-cert-tls client
\end{lstlisting}
\paragraph{Kryptografische Parameter:}
Um Konfigurationsprobleme durch abweichende Konfiguration von Client und Server auszuschließen, werden alle folgenden Parameter in \textbf{Client- und Serverkonfiguration} eingetragen.
Wie in Kapitel~\ref{sct:plan_openvpn_server} bereits erläutert, werden die kryptografischen Parameter wie folgt in \textbf{Client- und Serverkonfiguration} eingetragen.
Die TLS-Kommunikation wird über TLS Version~1.2 oder höher durchgeführt:
\begin{lstlisting}
@ -954,7 +955,7 @@ Ein zweiter Parameter erlaubt die Definition eines Zeitlimits, nachdem dessen Ab
\begin{lstlisting}
keepalive 10 30
\end{lstlisting}
Diese Anweisung sorgt dafür, dass der Server alle 10 Sekunden eine Ping-Nachricht an den Client schickt und nach einem Zeitlimit von 60 Sekunden ohne Erhalt einer Antwort die Sitzung beendet und damit verbundene Ressourcen wieder freigibt.
Diese Anweisung sorgt dafür, dass der Server alle 10 Sekunden eine Ping-Nachricht an den Client schickt, und nach einem Zeitlimit von 60 Sekunden ohne Erhalt einer Antwort die Sitzung beendet, und damit verbundene Ressourcen wieder freigibt.
Gleichzeitig wird die Anweisung über \texttt{push} an den Client übermittelt, sodass dieser ebenfalls alle 10 Sekunden eine Ping-Nachricht an den Server schickt.
Erhält der Client innerhalb von 30 Sekunden keine Antwort auf seine Ping-Nachricht, so startet er sich neu um einen erneuten Sitzungsaufbau zu versuchen.
@ -983,9 +984,9 @@ duplicate-cn
\paragraph{Lokale Sicherheit:}
Auf den Betriebssystemen Linux und Mac OS kann OpenVPN nach seinem Start nicht mehr benötigte Berechtigungen abgeben und im Kontext eines lokalen Benutzers weiterlaufen.
Dies kann in \textbf{Client- und Serverkonfiguration} bewerkstelligt werden.
OpenVPN kann unter diesen Bedingungen nicht auf bestimmte Ressourcen neuen Zugriffe starten.
Dazu gehören beispielsweise private Schlüssel für Zertifikate oder die virtuelle Netzwerkkarte.
Damit Aktionen wie ein Neustart von OpenVPN auch ohne Privilegien funktionieren können, ist es möglich mit \texttt{persist-tun} und \texttt{persist-key} das Handle auf die virtuelle Netzwerkkarte und bereits gelesene Schlüssel im Speicher zu behalten.
OpenVPN kann unter diesen Bedingungen auf bestimmte Ressourcen nicht erneut zugreifen.
Dazu gehören beispielsweise private Schlüssel für Zertifikate, oder die virtuelle Netzwerkkarte.
Damit ein Neustart von OpenVPN auch ohne Privilegien funktionieren kann, ist es möglich mit \texttt{persist-tun} und \texttt{persist-key} das Handle auf die virtuelle Netzwerkkarte, sowie bereits gelesene Schlüssel im Speicher zu behalten.
\begin{lstlisting}
persist-tun
persist-key
@ -1010,14 +1011,14 @@ Der Bereich reicht von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Fü
Für DSGVO-konforme Protokolle wird der Wert~0 in der \textbf{Serverkonfiguration} verwendet; der Wert~3 wird für übersichtliche Protokolle mit mehr Informationen in der \textbf{Clientkonfiguration} empfohlen.
Der Parameter \texttt{mute} gibt an, wie viele aufeinander folgende Nachrichten aus der selben Kategorie protokolliert werden sollen.
Damit können aufeinander folgende, ähnliche Nachrichten unterdrückt werden, die sich wiederholen.
Um einen guten Überblick zu erhalten, werden die folgenden Parameter gewählt:
Um einen guten Überblick im Testbetrieb zu erhalten, werden vorerst die folgenden Parameter gewählt:
\begin{lstlisting}
verb 3
mute 5
\end{lstlisting}
In der \textbf{Serverkonfiguration} kann mit \texttt{status} dafür gesorgt werden, dass OpenVPN regelmäßig eine Liste aller aktiven Sitzungen in die als Parameter angegebene Datei schreibt.
Eine solche Liste ist nützlich um die Auslastung des Servers zu überwachen.
Eine solche Liste ist nützlich, um die Auslastung des Servers zu überwachen.
\begin{lstlisting}
status inform/status.log
\end{lstlisting}