Begin structuring section for openvpn config

MA-Inhalt.tex

@@ -492,6 +492,18 @@ Lokale Firewall setzt folgende Regeln um
 Nachdem in den vorangegagenen Teilen der Arbeit alle für die Erstellung der OpenVPN-Konfiguration notwendigen Informationen ermittelt wurden, wird hier gezeigt und erklärt, wie sich die Client- und Serverkonfigurationen für OpenVPN ergeben.
 Dabei werden alle vorgenommenen Entscheidungen beleuchtet.
 
+\paragraph{Erreichbarkeit des Dienstes}
+Horcht auf IPv4 und IPv6, Client kann über DNS beide Adressen auflösen und je nach Verfügbarkeit der Protokolle die Sitzung aufbauen.
+Wir machen UDP, weil TCP in Kombination mit TCP im Tunnel Probleme bezüglich der ECN machen kann\todo{Quelle}.
+multihome, damit der OpenVPN-Server immer mit der richtigen IP-Adresse auf eingehende Pakete antwortet.
+
+\paragraph{IP-Adressen im VPN-Tunnel}
+server und server-ipv6
+topology subnet für IPv4
+
+\paragraph{Erreichbare Netze im VPN}
+push für route und route-ipv6
+
 \paragraph{Kompression}
 Auf Kompression wird verzichtet, da es bereits am 03.06.2018 Hinweise in der Manpage hinzugefügt wurden\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
 Zum Vergleich: OpenVPN Version~2.4.6 wurde von den Entwicklern am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben.
@@ -500,25 +512,46 @@ Zusätzlich wird in einem RFC\cite[][Kapitel 3.3]{RFC7525} auch zur Deaktivierun
 Auf der DEFCON~26 wird mit \enquote{VORACLE} ein in dieser Richtung relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}.
 
 \paragraph{Absicherung der Kommunikation}
+Kurze Erklärung Datenkanal (Symmetrische Verschlüsselung und HMAC) und Kontrollkanal (TLS mit HMAC)
+
+
 Wir sprechen nur TLS~1.2 oder höher.
 \begin{lstlisting}
 tls-version-min "1.2"
 \end{lstlisting}
+
 Die TLS-Chiffre \enquote{TLS-DHE-RSA-WITH-AES-256-GCM-SHA384} wird in \cite{bsi:tls-checkliste} und \cite{RFC7525} empfohlen.
 Diese wird zur Absicherung des Kontrolkanals verwendet.
 Eine Nutzung von ECDHE-Verfahren fällt leider Flach\footnote{Es existiert ein Problem in Kombination mit OpenSSL~1.1.x. Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
 \begin{lstlisting}
 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
 \end{lstlisting}
+
 Verschlüsselung der Daten im Datenkanal mit AES-256-GCM.
 \begin{lstlisting}
 cipher AES-256-GCM
 \end{lstlisting}
+Die Aushandlung dieses Ciphers ist auf der Serverseite deaktiviert mit ncp-disable
+
+
 Die Hashfunktion SHA-256 wird als message digest algorithm in HMAC verwendet, um die Pakete in Daten- und Kontrollkanal zu authentisieren.
 \begin{lstlisting}
 auth SHA256
 \end{lstlisting}
 
+\paragraph{Zertifikate und DH-Parameter}
+Dateiangaben, die TLS-Rolle, welche Sorte von Zertifikat erwartet wird, gegen welches CA das präsentierte Zertifikat geprüft wird.
+
+\paragraph{Sitzungsparameter}
+Mit keepalive wird ständig geprüft, ob der Sitzungspartner noch da ist.
+Das connect-timeout von 20 Sekunden sollte ausreichen und macht Verbindungsprobleme schneller sichtbar.
+explicit-exit-notify wird verwendet, um dem Sitzungspartner das Ende der Sitzung mitzuteilen - damit kann ein neuer Sitzungsaufbau früher wieder versucht werden.
+duplicate-cn, um mehr als eine gleichzeitige Sitzung pro Benutzer zu erlauben
+
+\paragraph{Lokale Sicherheit}
+persist-key, persist-tun für user und group
+Auf Clients zusätzlich auth-nocache
+
 
 \chapter{Fazit}
 Wie ist es gelaufen, gab es Probleme? Wie macht sich OpenVPN als Lösung?