Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- projekte:vpn:start [14.08.2018 07:31] – christf
+++ projekte:vpn:start [15.09.2018 18:34] (aktuell) – [Wireguard] christf
@@ Zeile 1: / Zeile 1: @@
-Übersicht über ausgewählte VPN-Technologien
+====== Übersicht über ausgewählte VPN-Technologien ======
 ^           ^  fastd   ^ wireguard ^ l2tp ^
-| Stärke    |  Unterstützt l2 und l3 Netze        |  schnell         | schnell     |
+| Stärke    |  Unterstützt l2 und l3 Netze, ist vorhanden        |  doppelt so schnell wie fastd         | schnell (wie schnell?)     |
 | Challenge |   ist langsam         | viele Interfaces serverseitig , ausschließlich l3 Netze |  keine Authentifizierung    |
+====== Wireguard ======
+Wireguard ist neu, schnell und dem Anschein nach gut geeignet für layer 3 Netze. Folgende Herausforderungen wurden durch die Integration gelöst.
+===== Integration in Gluon =====
+  * Hierfür wird ein eigenes Protokoll geschaffen 'gluon_wireguard'
+  * Interfaces werden mit einer statischen ll-Adresse konfiguriert. Serverseitig fe80::1/64, am Node mit fe80::2/64
+  * public keys werden per TCP vom node zum Gateway übermittelt sodass dort Interfaces eingerichtet werden. Dabei wird auf dem wireguard-Port mit TCP-Protokoll kommuniziert. Der Serverdienst hierfür läuft auf dem gw.
+  * Hat ein Interface mehr als 7 Minuten keinen handshake gesehen, wird es serverseitig gelöscht. Ist am node ein handshake mehr als 7 Minuten nicht erfolgt, wird der brokerprozess mit keyübermittlung gestartet sofern er noch nicht läuft.
+  * traffic shaping ist bei mehr als einer VPN-Verbindung ineffektiv, weil es je peer ein eigenes interface gibt. Wir shapen auf dem wireguard-interface und aktivieren lediglich 1 peer. In dieser Konfiguration funktioniert es.
+===== Key Exchange =====
+Der Server muss alle Public Keys der Nodes kennen und Interfaces erzeugen. Im wireguard Contrib-Verzeichnis gibt es eine Beispielimplementierung von ncat-client-server in bash, durch die public keys vom node zum server transportiert werden und dort WG-Interfaces erzeugt werden.
+Hierbei kann eine Prüfung gegen eine vorher eingestellte whitelist erfolgen.
+===== Entfernung nicht benötigter Interfaces am Server =====
+Wir prüfen periodisch ob die Interfaces aktiv sind und entfernen diese bei Inaktivität. Neuanlage erfolgt bei Bedarf wie bei einem neuen Node mittels Key Exchange.
+Die Prüfung erfolgt auf Basis des latest_handshake.