Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
projekte:vpn:start [20.08.2018 07:13] – [Wireguard] christf | projekte:vpn:start [15.09.2018 18:34] (aktuell) – [Wireguard] christf | ||
---|---|---|---|
Zeile 8: | Zeile 8: | ||
====== Wireguard ====== | ====== Wireguard ====== | ||
- | Wireguard ist neu, schnell und dem Anschein nach gut geeignet für layer 3 Netze. Folgende Herausforderungen | + | Wireguard ist neu, schnell und dem Anschein nach gut geeignet für layer 3 Netze. Folgende Herausforderungen |
===== Integration in Gluon ===== | ===== Integration in Gluon ===== | ||
- | * Hierfür wird ein eigenes Protokoll geschaffen 'wireguard' | + | |
- | * Interfaces werden mit einer statischen ll-Adresse konfiguriert. Serverseitig fe80::1/64, am Node mit fe80:: | + | * Interfaces werden mit einer statischen ll-Adresse konfiguriert. Serverseitig fe80::1/64, am Node mit fe80:: |
- | * 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. | + | * 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. | + | * 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 |
- | * 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 | + | * traffic shaping ist bei mehr als einer VPN-Verbindung ineffektiv, weil es je peer ein eigenes interface gibt. Wir shapen |
===== Key Exchange ===== | ===== Key Exchange ===== | ||
Zeile 21: | Zeile 21: | ||
Hierbei kann eine Prüfung gegen eine vorher eingestellte whitelist erfolgen. | Hierbei kann eine Prüfung gegen eine vorher eingestellte whitelist erfolgen. | ||
===== Entfernung nicht benötigter Interfaces am Server ===== | ===== Entfernung nicht benötigter Interfaces am Server ===== | ||
- | Bislang gibt es die Idee, periodisch | + | Wir prüfen |
- | + | ||
- | 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, | + | |
- | * ES gibt in wireguard ein last_handshake. Ist der nutzbar? | + | |
+ | Die Prüfung erfolgt auf Basis des latest_handshake. | ||