Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- projekte:vpn:start [20.08.2018 08:29] – [Integration in Gluon] christf
+++ projekte:vpn:start [15.09.2018 18:34] (aktuell) – [Wireguard] christf
@@ 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 'wireguard'
+  * 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. Auf dem müsste man shapen, in Gesamtsumme kommt am wan-interface mehr traffic an als geplant. Wie lösen wir das?
+  * 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 21: / 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 (haben wir angeschaut, geht nicht). 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.
-  * ES gibt in wireguard ein last_handshake. Ist der nutzbar?
+Die Prüfung erfolgt auf Basis des latest_handshake.