WireGuard wird in LANconfig unter konfiguriert.
- WireGuard aktiviert
- Aktiviert oder Deaktiviert die WireGuard-Funktion im Gerät.
- Cookie Challenge
- Die Cookie Challenge ist eine Schutzmechanismus vor CPU-Erschöpfungsangriffen während des Handshakes. Grundsätzlich ist die Berechnung der Diffie-Hellman (DH)-Funktion während des WireGuard-Handshakes sehr CPU-intensiv. Ein Angreifer könnte versuchen, den Router mit einer großen Anzahl von Handshake-Anfragen zu überlasten, um ihn zum Absturz zu bringen oder seine Leistung stark zu beeinträchtigen (CPU-Erschöpfungsangriff). Dieser Mechanismus zwingt den Angreifer, für jede Handshake-Anfrage einen zusätzlichen Netzwerk-Roundtrip durchzuführen und das Cookie zu beantworten. Dies erhöht die Kosten für den Angriff erheblich und macht ihn weniger effektiv. Es ermöglicht dem Server, die Anzahl der tatsächlich durchgeführten DH-Berechnungen zu begrenzen und seine Ressourcen zu schützen. Wenn die Cookie-Challenge aktiviert ist, sendet das Gerät beim Handshake immer eine Cookie-Reply-Nachricht.
- Verbindungsliste
-
In dieser werden die WireGuard-Verbindungen definiert.
- Verbindung
- Name der WireGuard-Verbindung bzw. der WireGuard-Gegenstelle.
- Verbindung aktiv
- Aktiviert bzw. Deaktiviert diese Verbindung.
- Automatisch aufbauen
- Definiert, ob der WireGuard-Tunnel automatisch – z. B. nach dem Gerätestart oder nach dem Aufbau der WAN-Verbindung – aufgebaut werden soll, oder nur dann, wenn tatsächlich Nutzdaten übertragen werden. Dieser Schalter muss zusammen mit dem Schalter "Persistent-Keepalive" konfiguriert werden, damit sich die WireGuard-Gegenstelle wie andere Gegenstellen verhält, die dauerhaft aktiv gehalten werden sollen. Bei "Ja" wird die WireGuard-Verbindung unabhängig vom Nutzdatenverkehr permanent aufgebaut. Bei "Nein" wird die Verbindung nur bei vorhandenem Nutzdatenverkehr aufgebaut.
- Lokaler Port
- Definiert den lokalen (UDP-)Port auf dem diese Verbindung vom Gerät angenommen werden soll. Pro Port muss der konfigurierte lokale Private-Key identisch sein. Mehrere konfigurierte Verbindungen auf dem gleichen lokalen Port und unterschiedlichen Private-Keys werden nicht unterstützt und führen dazu, dass Verbindungen nicht aufgebaut werden können bzw. die interne Konfiguration nicht erzeugt werden kann. Bei einem WireGuard-Tunnel mit IPv6 als Transportprotokoll müssen in der IPv6-Firewall in der Inbound-Tabelle die eingehenden UDP-Ports für den Tunnel manuell konfiguriert bzw. erlaubt werden.
- Remote Gateway
- IPv4-, IPv6- oder DNS-Adresse des entfernten Gateways oder Clients. Ist die IP-Adresse der remote Seite unbekannt oder dynamisch, so kann der Eintrag leer gelassen werden. In diesem Fall muss die Verbindung von der entfernten Seite aufgebaut werden. Wird eine explizite IP-Adresse konfiguriert, so muss diese beim Verbindungsaufbau exakt übereinstimmen. Erlaubte Werte: IPv4-Adresse, IPv6-Adresse, 0.0.0.0, :: oder leerer Eintrag. Die Werte 0.0.0.0 bzw. :: für IPv6 haben die gleiche Funktion wie ein leerer Eintrag.
- Remote Port
- Port der Seite des entfernten Gateways. Ist der entfernte Port von eingehenden Verbindungen dynamisch oder unbekannt, so kann der Eintrag leer gelassen werden oder mit 0 konfiguriert werden. Wird ein expliziter Port konfiguriert, so muss dieser beim Verbindungsaufbau exakt übereinstimmen und wird im Fehlerfall verworfen bzw. abgelehnt. Erlaubte Werte: Port, 0, leerer Eintrag
- Routing Tag
- Routing Tag, über das die WireGuard-Verbindung aufgebaut werden soll.
- Local Private Key
- Lokaler Private-Key der WireGuard-Verbindung im Base64-Format. Einträge im Hex-Key-Format werden nicht unterstützt. Aus dem lokalen Private-Key berechnet das Gerät automatisch seinen Public-Key. Pro lokalen Port muss der konfigurierte lokale Private-Key identisch sein. Mehrere konfigurierte Verbindungen auf dem gleichen lokalen Port und unterschiedlichen Private-Keys werden nicht unterstützt und führen dazu, dass Verbindungen nicht aufgebaut werden können bzw. die interne Konfiguration nicht erzeugt werden kann. Der lokale Private Key ist geheim und wird in der Regel nicht mit der entfernen Seite geteilt. Es sei denn, ein Administrator erstellt Schlüsselpaare für seine verwalteten Geräte. In diesem Fall kennt der Administrator alle Schlüsselpaare seiner Geräte.
- Peer Public Key
- Public Key des entfernten bzw. Remote-Gateways im Base64-Format. Einträge im Hex-Key-Format werden nicht unterstützt. Jeder Kommunikationspartner der WireGuard-Verbindung muss ein individuelles Schlüsselpaar aus Public-/Private-Key erzeugen und der entfernen Seite seinen Public-Key mitteilen.
- Peer Private Key
- Der Peer Private Key ist optional und wird nur dann konfiguriert, wenn LANconfig für die Gegenseite eine Konfiguration bzw. QR-Code erzeugen soll. Er ist für die Funktion im LCOS nicht erforderlich und wird nur in der Konfiguration gespeichert, damit die Konfiguration für die Gegenseite ggf. zu einem späteren Zeitpunkt erneut angezeigt bzw. generiert werden kann.
- Preshared Key
- Optionaler zusätzlicher Schlüssel, der bei der Verbindung neben dem Public-/Private-Schlüsselpaar verwendet werden soll. Der Schlüssel muss auf beiden Kommunikationspartnern identisch konfiguriert werden.
- IPv6-Profil
- Dieser Eintrag definiert das IPv6-WAN-Profil. Ein leerer Eintrag schaltet IPv6 für dieses Interface ab. Die IPv6-WAN-Profile konfigurieren Sie unter .
- Persistent Keepalive
- Definiert die Zeit in Sekunden, in der das entfernte Gerät (Peer) WireGuard Keepalive-Pakete senden soll. Der Wert 0 deaktiviert das Senden von Keepalive-Paketen. Das "Persistent Keepalive" in WireGuard sorgt dafür, dass die Verbindung auch dann aktiv gehalten wird, wenn gerade kein Datenverkehr stattfindet. Durch das regelmäßige Senden von Keepalive-Paketen wird die Verbindung, z. B. in NAT-Gateways auf der Strecke, aktiv gehalten und verhindert so ungewollte Verbindungsabbrüche.
- Kommentar
- Geben Sie einen Kommentar zu diesem Eintrag an.
