Einrichten br0ohne VPN

Question

Es handelt sich um zwei Fragen in derselben Frage, die eigentlich nicht voneinander abhängen. Ich werde trotzdem beide beantworten.

Außerdem deutet die noprefixrouteAdressoption darauf hin, dass ein Teil der Netzwerkkonfiguration von einem zusätzlichen Tool (wie NetworkManager) verwaltet wird, um Routen hinzuzufügen. Diese Antwort versucht nicht, sich mit der Integration in Netzwerktools zu befassen. Dies umfasst auch den Umgang mit der DHCP-Konfiguration, die die Änderungen später überschreiben könnte, wenn sie nicht richtig neu konfiguriert wird. Viele Einstellungen verschwinden, wenn die Schnittstelle heruntergefahren oder gelöscht wird, und müssen erneut vorgenommen werden. Dies geschieht daher am besten in verschiedenen Hooks verschiedener zuständiger Netzwerktools.

Einrichten `br0`ohne VPN

Eine als Bridge-Port festgelegte Schnittstelle verliert ihre Teilnahme am Routing

Sobald die Adresse als Bridge-Port festgelegt wurde, werden die mit der Schnittstelle verknüpften Routen ignoriert. Es können jedoch immer noch schädliche Nebenwirkungen auftreten, wenn die Adresse darauf belassen wird. Einzelheiten finden Sie im BlogRichtige Isolierung einer Linux-Brücke:

Übergabe des Rahmens an die gerätespezifischeEmpfangshandler, wenn überhaupt,

Übergabe des Frames an einen globalen oder gerätespezifischenProtokollhandler(zB IPv4, ARP, IPv6).

Für eine überbrückte Schnittstelle:Der Kernel hat einen gerätespezifischen Empfangshandler konfiguriert br_handle_frame(). Diese Funktion erlaubt keine weitere Verarbeitung im Kontext der eingehenden Schnittstelle, außer für STP- und LLDP-Frames oder wenn „brouting“ aktiviert ist. DaherDie Protokollhandler werden nie ausgeführtin diesem Fall.

Die IP-Adresse, die auf einer Schnittstelle festgelegt ist, die zu einem Bridge-Port wurde, sollte auf die Selbstschnittstelle der speziellen Bridge ( br0die Bridge selbst) verschoben werden, die als einzige am Routing teilnehmen kann (es gibt andere Optionen, aber wir halten es einfach). Dasselbe gilt für die relevanten Routen.

Nehmen wir an, das Standard-Gateway des OP ist 192.168.1.1/24. Schreiben wir dies für den ersten Fall neu:

ip link add name br0 up type bridge
ip link set dev enp7s0 master br0

ip address flush dev enp7s0
# previous command will also have removed all associated routes as a side effect
ip address add 192.168.1.100/24 dev br0
# previous command added the LAN route too as a side effect (no noprefixroute here)
ip route add default via 192.168.1.1

Damit können sowohl der Host als auch die VM auf das Internet zugreifen.

Beachten Sie, dass es sich beim VM-Teil vnet5auch um einen Bridge-Port handelt und dieser ebenfalls nicht am Routing teilnimmt. Der Host schaltet lediglich Frames zwischen VM und Router (192.168.1.1) um: kein Routing beteiligt.

Mit VPN und der `tun0`Schnittstelle

OpenVPN basiert auf dem TUN/TAP-Treiber (unter Linux bereitgestellt durch das Kernelmodultun). Der Fahrer kann Folgendes bereitstellen:

entweder eine Layer 2 TAP-Schnittstelle

Es verhält sich wie ein Ethernet-Gerät und kann als Ethernet-Bridge-Port festgelegt werden: Dieser wird vnet5vom VM-Hypervisor erstellt.
oder eine Layer 3 TUN Schnittstelle

Es enthält keine Frame-Informationen (Ethernet-MAC-Adresse) und verarbeitet auch keine Frames, sondern behandelt nur Protokolle auf oder über Schicht 3: IPv4 oder IPv6. Daher kann es nicht als Ethernet-Bridge-Port festgelegt werden. Das sind OPs, die tun0von OpenVPN im TUN-Modus erstellt werden.

OpenVPN kann auch den TAP-Modus verwenden, der überbrückt werden könnte, aber dazu ist eine Neukonfiguration der Remote-ServerSeite auch und das gesamte Netzwerklayout: Der Remote-Server wäre auch Teil des LAN 192.168.1.0/24. OP scheint keine Kontrolle darüber zu haben.

Überlegen wir also, was mit der TUN-Schnittstelle des OP getan werden kann: Dies erfolgt auf Ebene 3: Routing und nicht auf Ebene 2.

Wiederverwenden vorheriger Einstellungen nur für vertrauenswürdige VMs

Wenn der Host keine erweiterte Firewall, einschließlich Firewall-Einschränkungen und/oder Änderungen im Bridge-Pfad, beinhaltet, kann er eine VM nicht zwingen, sich selbst als Gateway zu verwenden: Eine wie zuvor überbrückte VM kann den Host einfach ignorieren und 192.168.1.1 als Gateway beibehalten, sodass ihr Datenverkehr tun0letztendlich nicht die Schnittstelle des Hosts verwendet.

Wenn die VM vertrauenswürdig ist und neu konfiguriert werden kann, können Sie br0wie oben beschrieben vorgehen und alle OpenVPN-Einstellungen basierend auf anwenden br0(wobei alle enp7s0Verweise durch ersetzt werden br0) und dies tun, sobald die VM läuft (mit der Adresse 192.168.1.221) und das VPN aktiv ist:

auf dem Host

Verwenden vonRichtlinien-/quellenbasiertes Routingum ein anderes Routenergebnis für diese bestimmte Quelle auszuwählen:

ip rule add from 192.168.1.221 lookup 1000
ip rule add iif tun0 lookup 1000
ip route add 192.168.1.0/24 dev br0 table 1000
ip route add default dev tun0 table 1000

Als Router festlegen:

sysctl -w net.ipv4.ip_forward=1

Und falls dieser Fall noch nicht durch eine ähnliche NAT-Regel abgedeckt ist:

  iptables -t nat -A POSTROUTING -s 192.168.1.221 -o tun0 -j MASQUERADE

Verwenden Sie auf (Linux-)VM den Host als Gateway anstelle des Routers des Hosts
```
ip route flush to default
ip route add default via 192.168.1.100
```

Empfohlen für nicht vertrauenswürdige VMs: Legen Sie die Hauptschnittstelle des Hosts nicht als Bridge-Port fest

Dadurch lässt sich der Datenverkehr der VM leichter durchsetzen, tun0da diese keinen Einblick in die Teile des Netzwerks hat, die sie nicht manipulieren sollte.

VM-Einstellungen ändern, um das eigene IP-Netzwerk zu verwenden

Beispiel: 192.168.100.0/24 und eine statische IP 192.168.100.2/24 (anstelle des Netzwerk-DHCP des Hosts) mit einem Standard-Gateway 192.168.100.1. Auf einer Linux-VM:
```
ip address add 192.168.100.2/24 dev enp1s0
ip route add default via 192.168.100.1
```
Auf dem Host mit der Erstkonfiguration beginnen (ohne Bridging enp7s0)

Man könnte sogar mit Nullbrücke unten auskommen (also direkt ip address add 192.168.100.1/24 dev vnet5mit vnet5nicht als Brückenport gesetzt), aberlibvirtkönnte dies erschweren.

Verwenden Sie einfach eine dedizierte Brücke für VMs (hier mit der Adresse 192.168.100.1/24, obwohl normalerweiselibvirtstellt eine Standardbrücke virbr0mit 192.168.122.1/24 bereit):
```
ip link add name br0 up type bridge
ip address add 192.168.100.1/24 dev br0
ip link set dev vnet5 master br0
```
Und verwenden Sie auchRichtlinienroutingum das Verhalten des mit den VM(s) verbundenen Datenverkehrs für die beiden beteiligten Schnittstellen zu ändern: br0und tun0. Wie üblich sind einige Duplikate und Änderungen vorhandener Routen in einer alternativen Routing-Tabelle erforderlich. Hier tun0wird angenommen, dass nur der Host und seine VM(s) bedient werden. Das Endziel ist: Alles, was von der VM-Seite kommt, wird an die Tun-Seite weitergeleitet, alles, was von der TUN-Seite kommt, wird an die VM-Seite weitergeleitet, wobei alle nicht benötigten Seiten ignoriert werden.
```
ip rule add iif br0 lookup 2000
ip rule add iif tun0 lookup 2000
ip route add 192.168.100.0/24 dev br0 table 2000
ip route add default dev tun0 table 2000 # layer 3 interfaces don't need a gateway
```
Hinweis: eingehende Pakete, die tun0für den Host bestimmt sind (d. h. nicht geroutet werden), werden bereits vomlokalRouting-Tabelle und benötigen keine zusätzliche Route in Tabelle 2000.

Als Router festlegen:
```
sysctl -w net.ipv4.ip_forward=1
```
Schließen Sie dann mit NAT ab, da der Remote-OpenVPN-Server 192.168.100.0/24 nicht kennt:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
```

Wenn die VM weiterhin das LAN 192.168.1.0/24 erreichen soll:

Aktualisieren Sie Tabelle 2000 erneut, um dies zu berücksichtigen

Duplizieren Sie die LAN-Route vom Haupttisch zum Tisch 2000:
```
ip route add 192.168.1.0/24 dev enp7s0 table 2000
```
und füge wieder eine entsprechende MASQUERADE-Regel hinzu

... da sich die VM jetzt in einem anderen LAN befindet, von dem andere Systeme nichts wissen:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
```
(Eine Faktorisierung einiger Iptables-Regeln wäre möglich).

Answer 1

Es handelt sich um zwei Fragen in derselben Frage, die eigentlich nicht voneinander abhängen. Ich werde trotzdem beide beantworten.

Außerdem deutet die noprefixrouteAdressoption darauf hin, dass ein Teil der Netzwerkkonfiguration von einem zusätzlichen Tool (wie NetworkManager) verwaltet wird, um Routen hinzuzufügen. Diese Antwort versucht nicht, sich mit der Integration in Netzwerktools zu befassen. Dies umfasst auch den Umgang mit der DHCP-Konfiguration, die die Änderungen später überschreiben könnte, wenn sie nicht richtig neu konfiguriert wird. Viele Einstellungen verschwinden, wenn die Schnittstelle heruntergefahren oder gelöscht wird, und müssen erneut vorgenommen werden. Dies geschieht daher am besten in verschiedenen Hooks verschiedener zuständiger Netzwerktools.

Einrichten `br0`ohne VPN

Eine als Bridge-Port festgelegte Schnittstelle verliert ihre Teilnahme am Routing

Sobald die Adresse als Bridge-Port festgelegt wurde, werden die mit der Schnittstelle verknüpften Routen ignoriert. Es können jedoch immer noch schädliche Nebenwirkungen auftreten, wenn die Adresse darauf belassen wird. Einzelheiten finden Sie im BlogRichtige Isolierung einer Linux-Brücke:

Übergabe des Rahmens an die gerätespezifischeEmpfangshandler, wenn überhaupt,

Übergabe des Frames an einen globalen oder gerätespezifischenProtokollhandler(zB IPv4, ARP, IPv6).

Für eine überbrückte Schnittstelle:Der Kernel hat einen gerätespezifischen Empfangshandler konfiguriert br_handle_frame(). Diese Funktion erlaubt keine weitere Verarbeitung im Kontext der eingehenden Schnittstelle, außer für STP- und LLDP-Frames oder wenn „brouting“ aktiviert ist. DaherDie Protokollhandler werden nie ausgeführtin diesem Fall.

Die IP-Adresse, die auf einer Schnittstelle festgelegt ist, die zu einem Bridge-Port wurde, sollte auf die Selbstschnittstelle der speziellen Bridge ( br0die Bridge selbst) verschoben werden, die als einzige am Routing teilnehmen kann (es gibt andere Optionen, aber wir halten es einfach). Dasselbe gilt für die relevanten Routen.

Nehmen wir an, das Standard-Gateway des OP ist 192.168.1.1/24. Schreiben wir dies für den ersten Fall neu:

ip link add name br0 up type bridge
ip link set dev enp7s0 master br0

ip address flush dev enp7s0
# previous command will also have removed all associated routes as a side effect
ip address add 192.168.1.100/24 dev br0
# previous command added the LAN route too as a side effect (no noprefixroute here)
ip route add default via 192.168.1.1

Damit können sowohl der Host als auch die VM auf das Internet zugreifen.

Beachten Sie, dass es sich beim VM-Teil vnet5auch um einen Bridge-Port handelt und dieser ebenfalls nicht am Routing teilnimmt. Der Host schaltet lediglich Frames zwischen VM und Router (192.168.1.1) um: kein Routing beteiligt.

Mit VPN und der `tun0`Schnittstelle

OpenVPN basiert auf dem TUN/TAP-Treiber (unter Linux bereitgestellt durch das Kernelmodultun). Der Fahrer kann Folgendes bereitstellen:

entweder eine Layer 2 TAP-Schnittstelle

Es verhält sich wie ein Ethernet-Gerät und kann als Ethernet-Bridge-Port festgelegt werden: Dieser wird vnet5vom VM-Hypervisor erstellt.
oder eine Layer 3 TUN Schnittstelle

Es enthält keine Frame-Informationen (Ethernet-MAC-Adresse) und verarbeitet auch keine Frames, sondern behandelt nur Protokolle auf oder über Schicht 3: IPv4 oder IPv6. Daher kann es nicht als Ethernet-Bridge-Port festgelegt werden. Das sind OPs, die tun0von OpenVPN im TUN-Modus erstellt werden.

OpenVPN kann auch den TAP-Modus verwenden, der überbrückt werden könnte, aber dazu ist eine Neukonfiguration der Remote-ServerSeite auch und das gesamte Netzwerklayout: Der Remote-Server wäre auch Teil des LAN 192.168.1.0/24. OP scheint keine Kontrolle darüber zu haben.

Überlegen wir also, was mit der TUN-Schnittstelle des OP getan werden kann: Dies erfolgt auf Ebene 3: Routing und nicht auf Ebene 2.

Wiederverwenden vorheriger Einstellungen nur für vertrauenswürdige VMs

Wenn der Host keine erweiterte Firewall, einschließlich Firewall-Einschränkungen und/oder Änderungen im Bridge-Pfad, beinhaltet, kann er eine VM nicht zwingen, sich selbst als Gateway zu verwenden: Eine wie zuvor überbrückte VM kann den Host einfach ignorieren und 192.168.1.1 als Gateway beibehalten, sodass ihr Datenverkehr tun0letztendlich nicht die Schnittstelle des Hosts verwendet.

Wenn die VM vertrauenswürdig ist und neu konfiguriert werden kann, können Sie br0wie oben beschrieben vorgehen und alle OpenVPN-Einstellungen basierend auf anwenden br0(wobei alle enp7s0Verweise durch ersetzt werden br0) und dies tun, sobald die VM läuft (mit der Adresse 192.168.1.221) und das VPN aktiv ist:

auf dem Host

Verwenden vonRichtlinien-/quellenbasiertes Routingum ein anderes Routenergebnis für diese bestimmte Quelle auszuwählen:

ip rule add from 192.168.1.221 lookup 1000
ip rule add iif tun0 lookup 1000
ip route add 192.168.1.0/24 dev br0 table 1000
ip route add default dev tun0 table 1000

Als Router festlegen:

sysctl -w net.ipv4.ip_forward=1

Und falls dieser Fall noch nicht durch eine ähnliche NAT-Regel abgedeckt ist:

  iptables -t nat -A POSTROUTING -s 192.168.1.221 -o tun0 -j MASQUERADE

Verwenden Sie auf (Linux-)VM den Host als Gateway anstelle des Routers des Hosts
```
ip route flush to default
ip route add default via 192.168.1.100
```

Empfohlen für nicht vertrauenswürdige VMs: Legen Sie die Hauptschnittstelle des Hosts nicht als Bridge-Port fest

Dadurch lässt sich der Datenverkehr der VM leichter durchsetzen, tun0da diese keinen Einblick in die Teile des Netzwerks hat, die sie nicht manipulieren sollte.

VM-Einstellungen ändern, um das eigene IP-Netzwerk zu verwenden

Beispiel: 192.168.100.0/24 und eine statische IP 192.168.100.2/24 (anstelle des Netzwerk-DHCP des Hosts) mit einem Standard-Gateway 192.168.100.1. Auf einer Linux-VM:
```
ip address add 192.168.100.2/24 dev enp1s0
ip route add default via 192.168.100.1
```
Auf dem Host mit der Erstkonfiguration beginnen (ohne Bridging enp7s0)

Man könnte sogar mit Nullbrücke unten auskommen (also direkt ip address add 192.168.100.1/24 dev vnet5mit vnet5nicht als Brückenport gesetzt), aberlibvirtkönnte dies erschweren.

Verwenden Sie einfach eine dedizierte Brücke für VMs (hier mit der Adresse 192.168.100.1/24, obwohl normalerweiselibvirtstellt eine Standardbrücke virbr0mit 192.168.122.1/24 bereit):
```
ip link add name br0 up type bridge
ip address add 192.168.100.1/24 dev br0
ip link set dev vnet5 master br0
```
Und verwenden Sie auchRichtlinienroutingum das Verhalten des mit den VM(s) verbundenen Datenverkehrs für die beiden beteiligten Schnittstellen zu ändern: br0und tun0. Wie üblich sind einige Duplikate und Änderungen vorhandener Routen in einer alternativen Routing-Tabelle erforderlich. Hier tun0wird angenommen, dass nur der Host und seine VM(s) bedient werden. Das Endziel ist: Alles, was von der VM-Seite kommt, wird an die Tun-Seite weitergeleitet, alles, was von der TUN-Seite kommt, wird an die VM-Seite weitergeleitet, wobei alle nicht benötigten Seiten ignoriert werden.
```
ip rule add iif br0 lookup 2000
ip rule add iif tun0 lookup 2000
ip route add 192.168.100.0/24 dev br0 table 2000
ip route add default dev tun0 table 2000 # layer 3 interfaces don't need a gateway
```
Hinweis: eingehende Pakete, die tun0für den Host bestimmt sind (d. h. nicht geroutet werden), werden bereits vomlokalRouting-Tabelle und benötigen keine zusätzliche Route in Tabelle 2000.

Als Router festlegen:
```
sysctl -w net.ipv4.ip_forward=1
```
Schließen Sie dann mit NAT ab, da der Remote-OpenVPN-Server 192.168.100.0/24 nicht kennt:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
```

Wenn die VM weiterhin das LAN 192.168.1.0/24 erreichen soll:

Aktualisieren Sie Tabelle 2000 erneut, um dies zu berücksichtigen

Duplizieren Sie die LAN-Route vom Haupttisch zum Tisch 2000:
```
ip route add 192.168.1.0/24 dev enp7s0 table 2000
```
und füge wieder eine entsprechende MASQUERADE-Regel hinzu

... da sich die VM jetzt in einem anderen LAN befindet, von dem andere Systeme nichts wissen:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
```
(Eine Faktorisierung einiger Iptables-Regeln wäre möglich).

Einrichten br0ohne VPN