Wireguard funktioniert auch ohne Festlegen einer Tunnel-IP-Adresse, d. h. es reicht aus, die zulässigen IPs, Endpunktadressen sowie privaten und öffentlichen Schlüssel festzulegen.
In den Dokumenten vonOpnSensegibt es folgende Warnung:
Notiz:Die Tunneladresse muss in CIDR-Notation angegeben werden und muss eine eindeutige IP und ein eindeutiges Subnetz für Ihr Netzwerk sein. [..]Verwenden Sie keine Tunneladresse, die /32 (IPv4) oder /128 (IPv6) ist.
und pfSense hat eine wahrscheinliche Erklärung:
Notiz:Routen werden in der Systemroutingtabelle nicht automatisch erstellt. Routen für andere Netzwerke als das Tunnelnetzwerk selbst müssen separat mithilfe statischer oder dynamischer Routen konfiguriert werden.
Eine Suche im Internet liefert nicht viele Erklärungen:
- Reddit: Verwirrung um Subnetzmasken
- Reddit: Hilfe zu /24 und /32 bei Verwendung als VPN-Server
- Reddit: Unterschiede zwischen /8, /16 usw. ... Wofür werden sie verwendet?
Das Subnetz scheint keine Funktionalität zu haben, wir haben einige Tests durchgeführt:
- Es hat keinen Bezug zur lokalen Verkehrsweiterleitung, d. h. die Weiterleitung zu einem zweiten verbundenen Peer funktioniert mit und ohne ein Subnetz, das beide Peers enthält.
- es hat nichts damit zu tun, ob der Datenverkehr „auf der Schnittstelle bleibt“ oder durch den Kernel geleitet wird. In beiden Fällen könnten wir den Datenverkehr mithilfe von Firewall-Regeln steuern.
Was ist also der Zweck der Subnetzmaske in der Tunnel-IP?
Antwort1
Die Subnetzmasketut nichtsWireGuard-spezifisch.
WireGuard selbst verwendet oder kümmert sich nicht um die Subnetzmasken seiner Schnittstellenadressen (oder verwendet oder kümmert sich nicht einmal um die Adressen selbst). Der Netzwerkstapel und andere Netzwerktools auf dem WireGuard-Host kümmern sich jedoch um die für jede Netzwerkschnittstelle registrierten IP-Adressen und Subnetze und versuchen anhand dieser herauszufinden, ob eine bestimmte Schnittstelle direkt an ein bestimmtes Netzwerk angeschlossen ist.
Ihr beobachtetes Verhalten kann je nach Betriebssystem und den von Ihnen verwendeten Netzwerktools (wie OPNSense/pfSense und all ihren verschiedenen Plugins) variieren, aber viele Dinge wie Routing-Tabellen, Firewall-Regeln, ARP-Nachrichten, Nachbartabellen usw. werden möglicherweise automatisch basierend auf den IP-Adressen und Subnetzen generiert, die Sie für jede Netzwerkschnittstelle konfiguriert haben. In vielen Fällen können Sie diese Standardeinstellungen jedoch immer noch durch benutzerdefinierte Routing-/Firewall-Regeln, Kernel-Einstellungen, Netzwerk-Daemon-Konfiguration usw. überschreiben.
Wenn Sie beispielsweise eine WireGuard-Schnittstelle mit dem Standard startenwg-schnellSkript unter Linux verwendet das Skript dieiproute2Tool, um jede Adresse und jedes Subnetz hinzuzufügen, das Sie für die Schnittstelle konfiguriert haben. Für jede hinzugefügte Adresse fügt iproute2 automatisch eine entsprechende Route zur Hauptroutingtabelle hinzu, die dem Subnetz der Adresse entspricht. Wenn Sie dieses Skript verwenden, um eine Schnittstelle wg0mit der Adresse „...“ zu starten 10.0.0.123/24, fügt iproute2 die folgende Route zur Hauptroutingtabelle hinzu:
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.123
Dies ist keine WireGuard-Sache, sondern lediglich das Standardverhalten einiger der Standardnetzwerktools unter Linux. Sie können diese Route löschen und andere Routen hinzufügen oder einfach einen anderen Satz von Tools verwenden, um die WireGuard-Schnittstelle einzurichten. (Denken Sie jedoch daran, dass diese oder alle anderen Routen, die einer WireGuard-Schnittstelle hinzugefügt werden und keinen entsprechenden AllowedIPsEintrag in der eigenen Konfiguration der Schnittstelle haben, effektiv zu einem schwarzen Loch werden.)
Das Fazit ist, dass es in den meisten Fällen völlig in Ordnung ist, eine Adresse mit einer /32- oder /128-Subnetzmaske auf einer WireGuard-Schnittstelle zu verwenden. Sie können Ihre eigenen Routing- und Firewall-Regeln einrichten, um den gewünschten Datenverkehr an diese Schnittstelle zu senden. In fortgeschritteneren Fällen – insbesondere, wenn Sie Tools wie Proxy ARP, NDP Proxy, OSPF usw. (die für die Verwendung in lokalen Subnetzen vorgesehen sind) auf der Schnittstelle ausführen möchten – können Sie das Standardverhalten dieser Tools vermeiden, indem Sie die WireGuard-Schnittstelle und ihre virtuellen Nachbarn einem konsistenten logischen Subnetz zuweisen.