Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- projekte:vpn:start [19.08.2018 08:27] – [Key Exchange] 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 ^
@@ Zeile 8: / Zeile 8: @@
 ====== Wireguard ======
-Wireguard ist neu, schnell und dem Anschein nach gut geeignet für layer 3 Netze. Folgende Herausforderungen sind zu lösen:
+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 =====
@@ Zeile 14: / Zeile 21: @@
 Hierbei kann eine Prüfung gegen eine vorher eingestellte whitelist erfolgen.
 ===== Entfernung nicht benötigter Interfaces am Server =====
-Bislang gibt es die Idee, periodisch zu prüfen ob die Interfaces aktiv sind und bei Inaktivität zu entfernen. Neuanlage erfolgt bei Bedarf wie bei einem neuen Node mittels Key Exchange.
+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.
-Wie prüft man ob das Interface noch da ist?
-  * man könnte periodisch pings schicken
-  * man könnte in der neighbour-Tabelle auf dem Server nachsehen. Sofern der remote noch da ist, gibt es dort einen Eintrag. Damit das sinnvoll funktioniert, muss ggf am Server das neighbour-purge-timeout (ähnlich wie bei l3roamd auch) heruntergeregelt werden.
+Die Prüfung erfolgt auf Basis des latest_handshake.