Soll der Verkehr an meine IPv4-Routen weitergeleitet werden, außer an die Adresse 0.0.0.0?

Soll der Verkehr an meine IPv4-Routen weitergeleitet werden, außer an die Adresse 0.0.0.0?

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_softetherist 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.4die IP-Adresse des anderen Endpunkts ist. Wenn Sie die defaultRegel 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 enp7s0ausgeschaltet wird. Diese Route erscheint nicht, wenn enp7s0online 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 enp7s0sie 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.4Die 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/32und 0.0.0.0/0das 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/0Minus 1.2.3.4/32ergibt 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 DisallowedIPsFunktionalität verfügt.

Meine Lösung besteht also darin, die Konfiguration wegzulassen AllowedIPsund selbst Standardrouten zu erstellen. Ich verwende FolgendesRechner-Ausschlussin Python geschrieben. Sie müssen Folgendes tun:

  1. Sammeln Sie alle Endpunkte aus allen Wireguard-Clientkonfigurationen.
  2. Alle Endpunkte auflösen.
  3. Zielendpunkte von 0.0.0.0/0(und von ::/0) ausschließen.
  4. 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.shund route-down.client.shalsö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

verwandte Informationen