
Wie leite ich den Verkehr an meine IPv4-Routen weiter, außer an die Adresse 0.0.0.0,
da ich nicht möchte, dass dies die Standardschnittstelle ist?
Standard über 192.168.5.1 dev enp7s0 proto dhcp metric 100 169.254.0.0/16 dev enp7s0 Bereich Link Metrik 1000 192.168.5.0/24 dev enp7s0 proto Kernel Bereich Link src 192.168.5.84 Metrik 100 192.168.60.0/24 dev vpn_softether proto Kernelbereich Link src 192.168.60.50 209.80.36.170 über 192.168.60.1 dev vpn_softether 216.117.82.227 über 192.168.60.1 dev vpn_softether
Ich möchte vpn_softether als Standardschnittstelle festlegen,
was ich bereits versucht habe …
ip r add 0.0.0.0/1 über 0.0.0.0 dev vpn_softether ip r add 128.0.0.0/1 über 0.0.0.0 dev vpn_softether ip r add 0.0.0.0/1 über 192.168.5.1 ip r add 128.0.0.0/1 über 192.168.5.1 ip r standardmäßig hinzufügen über 192.168.60.1 ip r del 0.0.0.0/1 über 192.168.60.1 dev vpn_softether ip r del 128.0.0.0/1 über 192.168.60.1 dev vpn_softether ip r del 0.0.0.0/1 über 192.168.5.1 ip r del 128.0.0.0/1 über 192.168.5.1 ip r add 0.0.0.0/1 über 192.168.5.1 dev enp7s0 proto dhcp metrik 100 ip r add 128.0.0.1/1 über 192.168.5.1 dev enp7s0 proto dhcp metrik 100 ip r del 0.0.0.0/1 über 192.168.5.1 dev enp7s0 proto dhcp metrik 100 ip r del Standard über 192.168.60.1 dev vpn_softether ip r del 128.0.0.0/1 über 192.168.5.1 dev enp7s0 proto dhcp metrik 100 ip r del 0.0.0.0/1 über 192.168.60.1 dev vpn_softether proto dhcp metrik 100 ip r del Standard über 192.168.5.1 dev enp7s0 ip r del 128.0.0.0/1 über 192.168.60.1 dev vpn_softether proto dhcp metrik 100 ip r add 0.0.0.0/1 über 192.168.60.1 dev vpn_softether ip r add default über 192.168.5.1 dev enp7s0 proto dhcp metric 100 ip r add 128.0.0.0/1 über 192.168.60.1 dev vpn_softether
aber es hat nicht funktioniert... Gibt es eine andere Möglichkeit, es zu tun?
Danke.
Antwort1
Beachten Sie, dass Sie "den gesamten Verkehr" nur weiterleiten können aneinsSchnittstelle, nicht zu irgendwie allen von ihnen.
Wenn Sie Ihre Standardroute beibehalten möchten (aus welchen Gründen auch immer), lassen Sie die Standardroute unverändert und fügen Sie sie nicht hinzu oder entfernen Sie sie nicht. Wenn Sie sie hinzufügen oder entfernen können, müssen Sie die Standardroute nicht beibehalten ...
Also,
ip route add 0.0.0.0/1 via 192.168.60.1 dev vpn_softether
ip route add 128.0.0.0/1 via 192.168.60.1 dev vpn_softether
sollte funktionieren, vorausgesetzt, das Gateway vpn_softether
ist tatsächlich 192.168.60.1
. Beachten Sie, dass Sie auch eine Regel benötigen, um überall dort, wo Ihr VPN verbunden ist, von aus zu senden enp7s0
, sonst kann das VPN nicht mit dem anderen Endpunkt kommunizieren und Sie haben infolgedessen überhaupt keine Verbindung. Also etwas wie
ip route add 1.2.3.4/32 via 192.168.5.1 dev enp7s0
wobei 1.2.3.4
die IP-Adresse des anderen Endpunkts ist. Wenn Sie die default
Regel dafür beibehalten (falls dies Ihre Motivation für diese Bedingung war), wirdnichtarbeiten.
Antwort2
Ich möchte der vorherigen Antwort noch Folgendes hinzufügen:
ip route add 1.2.3.4/32 via 192.168.5.1 dev enp7s0
Das ist der falsche Ansatz. Diese Route verschwindet, wenn enp7s0
ausgeschaltet wird. Diese Route erscheint nicht, wenn enp7s0
online gegangen wird. In der Zwischenzeit ist Ihre VPN-Schnittstelle zwar online, funktioniert aber nicht, weil sie nicht erreichbar ist 1.2.3.4
.
Sie können diese Route dynamisch mit netplan erstellen, sobald enp7s0
sie eingerichtet ist. Diese Route besteht jedoch aus einer IP-Adresse, einem Netzwerkschnittstellennamen und einer Gateway-IP. Das bedeutet, dass sienicht über verschiedene Netzwerke portierbar. Die Praxis zeigt, dass diese Lösung zu mühsam ist und daher nicht empfohlen wird. Sie werden kurzfristig vergessen, dass Sie eine wichtige Route zu Netplan hinzugefügt haben. Später wird diese Route für Sie zum Problem. Es ist völlig unmöglich, diese Lösung in einem großen Netzwerk zu verwenden.
1.2.3.4
Die richtige Lösung besteht darin , von der Standardroute, die Sie für die VPN-Verkehrsumleitung erstellen, auszuschließen . FürBeispiellösung für Wireguard. Sie müssen ausschließen 1.2.3.4/32
und 0.0.0.0/0
das Ergebnis in eingeben AllowedIPs
. OnlineRechner ist hier. Sie können dort einen Absatz „eine bessere Alternative“ lesen, aber der Autor irrt sich, es gibt keine Alternativen.
0.0.0.0/0
Minus 1.2.3.4/32
ergibt beispielsweise :
AllowedIPs = 0.0.0.0/8, 1.0.0.0/15, 1.2.0.0/23, 1.2.2.0/24, 1.2.3.0/30, 1.2.3.5/32, 1.2.3.6/31, 1.2.3.8/29, 1.2.3.16/28, 1.2.3.32/27, 1.2.3.64/26, 1.2.3.128/25, 1.2.4.0/22, 1.2.8.0/21, 1.2.16.0/20, 1.2.32.0/19, 1.2.64.0/18, 1.2.128.0/17, 1.3.0.0/16, 1.4.0.0/14, 1.8.0.0/13, 1.16.0.0/12, 1.32.0.0/11, 1.64.0.0/10, 1.128.0.0/9, 2.0.0.0/7, 4.0.0.0/6, 8.0.0.0/5, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/1
Leider ist diese Lösung nicht ideal: Sie können mehrere VPNs haben und müssen daher alle Endpunkt-IPs von jeder VPN-Standardroute ausschließen.
Wenn Sie beispielsweise zwei VPNs haben und ein weiteres hinzufügen möchten, müssen Sie die dritte Endpunkt-IP aus den zulässigen IPs der beiden vorhandenen VPN-Konfigurationen ausschließen. Es wäre besser, wenn Wireguard über einen internen Rechner oder eine interne DisallowedIPs
Funktionalität verfügt.
Meine Lösung besteht also darin, die Konfiguration wegzulassen AllowedIPs
und selbst Standardrouten zu erstellen. Ich verwende FolgendesRechner-Ausschlussin Python geschrieben. Sie müssen Folgendes tun:
- Sammeln Sie alle Endpunkte aus allen Wireguard-Clientkonfigurationen.
- Alle Endpunkte auflösen.
- Zielendpunkte von
0.0.0.0/0
(und von::/0
) ausschließen. - Fügen Sie Standardrouten für jeden IP-Block hinzu, den Sie vom Rechner erhalten haben.
PS: Ich kann Ihnen empfehlen, diese Routen für jede VPN-Schnittstelle in eine separate Tabelle einzutragen. Denn es wird eine ganze Menge davon geben.
PS Ich habe meine route-up.client.sh
und route-down.client.sh
alsöffentliches Wesentliche hier.
Table = off
PostUp = /etc/wireguard/route-up.client.sh 51820 wg0 10.20.3.0/24 fd10:20:3::/64 10
PreDown = /etc/wireguard/route-down.client.sh 51820