Configurando br0, sin VPN

Question

Hay dos preguntas en la misma pregunta y en realidad no dependen una de otra. Todavía responderé a ambos.

Además, la noprefixrouteopción de dirección sugiere que una parte de la configuración de la red se administra mediante alguna herramienta adicional (como NetworkManager) para agregar rutas. Esta respuesta no intentará abordar la integración en herramientas de red. Esto incluye lidiar con la configuración de DHCP, que podría anular los cambios más adelante si no se reconfigura correctamente. Muchas configuraciones desaparecen cuando la interfaz se desactiva o se elimina y deben realizarse nuevamente, por lo que es mejor hacerlo en varios ganchos de varias herramientas de red a cargo.

Configurando `br0`, sin VPN

Una interfaz configurada como puerto puente pierde su participación en el enrutamiento

Una vez configurado como puerto puente, las rutas asociadas con la interfaz se ignoran. Es posible que aún existan efectos secundarios dañinos al dejar la dirección en él. Los detalles se pueden encontrar en el blog.Aislamiento adecuado de un puente Linux:

entregue el marco a la persona encargada del dispositivorecibir controlador, Si alguna,

entregar el marco a un global o específico del dispositivomanejador de protocolo(por ejemplo, IPv4, ARP, IPv6).

Para una interfaz puenteada,El kernel ha configurado un controlador de recepción específico del dispositivo br_handle_frame(). Esta función no permitirá ningún procesamiento adicional en el contexto de la interfaz entrante, excepto para tramas STP y LLDP, o si la "generación" está habilitada. Por lo tanto,el Los controladores de protocolo nunca se ejecutan.en este caso.

La dirección IP configurada en una interfaz que se convirtió en un puerto puente debe trasladarse a la interfaz propia del puente especial ( br0: el puente en sí), que es la única capaz de participar en el enrutamiento (hay otras opciones, pero hagámoslo simple). Lo mismo ocurre con las rutas relevantes.

Supongamos que la puerta de enlace predeterminada de OP es 192.168.1.1/24. Reescribamos esto para el primer caso:

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

Con esto, tanto el host como la VM pueden acceder a Internet.

Tenga en cuenta que, para la parte VM, vnet5también es un puerto puente y tampoco participa en el enrutamiento. El host simplemente cambia tramas entre la máquina virtual y el enrutador (192.168.1.1): no implica enrutamiento.

Con VPN y la `tun0`interfaz

OpenVPN se basa en el controlador TUN/TAP (proporcionado en Linux por el módulo del kerneltun). El conductor puede proporcionar:

ya sea una interfaz TAP de capa 2

Se comporta como un dispositivo Ethernet y se puede configurar como un puerto puente Ethernet: lo vnet5crea el hipervisor VM.
o una interfaz TUN de capa 3

No incluye información de trama (dirección MAC de Ethernet) ni maneja tramas, sino que trata solo con protocolos en la capa 3 o superior: IPv4 o IPv6. Por lo tanto, no se puede configurar como puerto puente Ethernet. Son OP tun0creados por OpenVPN en modo TUN.

OpenVPN también puede usar el modo TAP que podría conectarse en puente, pero esto requiere reconfigurar el control remoto.servidorlado también y todo el diseño de la red: el servidor remoto también sería parte de la LAN 192.168.1.0/24. OP no parece tener control sobre ello.

Entonces, consideremos lo que se puede hacer con la interfaz TUN del OP: esto se hará en la capa 3: enrutamiento, y no en la capa 2.

Reutilizar la configuración anterior solo para máquinas virtuales confiables

Si el host no incluye firewall avanzado, incluidas restricciones de firewall y/o alteraciones en la ruta del puente, no puede forzar a una VM a usarse como puerta de enlace: una VM con puente como antes puede simplemente ignorar el host y mantener 192.168.1.1 como puerta de enlace y que su tráfico no utilice la interfaz del host tun0al final.

Si se puede confiar en la VM y reconfigurarla, se puede seguir br0como se indicó anteriormente, aplicar cualquier configuración de OpenVPN basada en br0(reemplazando cualquier enp7s0referencia con br0) y hacer esto una vez que la VM se esté ejecutando (con la dirección 192.168.1.221) y la VPN esté activa:

en el anfitrión

Usandoenrutamiento basado en políticas/fuentepara seleccionar un resultado de ruta diferente para esta fuente específica:

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

Establecer como enrutador:

sysctl -w net.ipv4.ip_forward=1

Y en caso de que ninguna regla NAT similar ya resuelva este caso:

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

en VM (Linux), use el host como puerta de enlace en lugar del enrutador del host
```
ip route flush to default
ip route add default via 192.168.1.100
```

Recomendado para máquinas virtuales que no son de confianza: no configure la interfaz principal del host como puerto puente

Esto hace que sea más fácil controlar el tráfico de la VM tun0porque no tendrá vista de las partes de la red que no debe alterar.

cambiar la configuración de VM para usar su propia red IP

Ejemplo: 192.168.100.0/24 y una IP estática 192.168.100.2/24 (en lugar del DHCP de la red del host), con una puerta de enlace predeterminada 192.168.100.1. En una máquina virtual Linux:
```
ip address add 192.168.100.2/24 dev enp1s0
ip route add default via 192.168.100.1
```
En el host, comience desde la configuración inicial (sin puentes enp7s0)

Incluso se podría utilizar el puente cero a continuación (es decir, directamente ip address add 192.168.100.1/24 dev vnet5sin vnet5configurarlo como puerto puente), perolibvirtpodría hacer esto más difícil.

Simplemente tenga un puente dedicado para máquinas virtuales (aquí usando la dirección 192.168.100.1/24, aunque generalmentelibvirtproporciona un puente predeterminado virbr0con 192.168.122.1/24):
```
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
```
Y también usarenrutamiento de políticaspara cambiar el comportamiento del tráfico relacionado con las VM para las dos interfaces involucradas: br0y tun0. Como es habitual, implica algunas duplicaciones y modificaciones de rutas existentes en una tabla de enrutamiento alternativa. Aquí tun0se supone que solo se da servicio al host y sus máquinas virtuales. El objetivo final es: todo lo que viene del lado VM se enruta al lado tun, todo lo que viene del lado TUN se enruta al lado VM, sin tener en cuenta cualquier lado no necesario.
```
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
```
Nota: los paquetes entrantes tun0destinados al host (es decir, no enrutados) ya son manejados por ellocaltabla de enrutamiento y no necesita ninguna ruta adicional en la tabla 2000.

Establecer como enrutador:
```
sysctl -w net.ipv4.ip_forward=1
```
Luego complete con NAT ya que el servidor OpenVPN remoto no conoce 192.168.100.0/24:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
```

Si la VM aún debería poder alcanzar la LAN 192.168.1.0/24:

actualice nuevamente la tabla 2000 para acomodar esto

Duplicar la ruta LAN desde la tabla principal a la tabla 2000:
```
ip route add 192.168.1.0/24 dev enp7s0 table 2000
```
y agregue nuevamente una regla MASQUERADE adecuada

... ya que VM ahora está en una LAN diferente que otros sistemas no conocen:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
```
(Se podrían realizar la factorización de algunas reglas de iptables).

Answer 1

Hay dos preguntas en la misma pregunta y en realidad no dependen una de otra. Todavía responderé a ambos.

Además, la noprefixrouteopción de dirección sugiere que una parte de la configuración de la red se administra mediante alguna herramienta adicional (como NetworkManager) para agregar rutas. Esta respuesta no intentará abordar la integración en herramientas de red. Esto incluye lidiar con la configuración de DHCP, que podría anular los cambios más adelante si no se reconfigura correctamente. Muchas configuraciones desaparecen cuando la interfaz se desactiva o se elimina y deben realizarse nuevamente, por lo que es mejor hacerlo en varios ganchos de varias herramientas de red a cargo.

Configurando `br0`, sin VPN

Una interfaz configurada como puerto puente pierde su participación en el enrutamiento

Una vez configurado como puerto puente, las rutas asociadas con la interfaz se ignoran. Es posible que aún existan efectos secundarios dañinos al dejar la dirección en él. Los detalles se pueden encontrar en el blog.Aislamiento adecuado de un puente Linux:

entregue el marco a la persona encargada del dispositivorecibir controlador, Si alguna,

entregar el marco a un global o específico del dispositivomanejador de protocolo(por ejemplo, IPv4, ARP, IPv6).

Para una interfaz puenteada,El kernel ha configurado un controlador de recepción específico del dispositivo br_handle_frame(). Esta función no permitirá ningún procesamiento adicional en el contexto de la interfaz entrante, excepto para tramas STP y LLDP, o si la "generación" está habilitada. Por lo tanto,el Los controladores de protocolo nunca se ejecutan.en este caso.

La dirección IP configurada en una interfaz que se convirtió en un puerto puente debe trasladarse a la interfaz propia del puente especial ( br0: el puente en sí), que es la única capaz de participar en el enrutamiento (hay otras opciones, pero hagámoslo simple). Lo mismo ocurre con las rutas relevantes.

Supongamos que la puerta de enlace predeterminada de OP es 192.168.1.1/24. Reescribamos esto para el primer caso:

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

Con esto, tanto el host como la VM pueden acceder a Internet.

Tenga en cuenta que, para la parte VM, vnet5también es un puerto puente y tampoco participa en el enrutamiento. El host simplemente cambia tramas entre la máquina virtual y el enrutador (192.168.1.1): no implica enrutamiento.

Con VPN y la `tun0`interfaz

OpenVPN se basa en el controlador TUN/TAP (proporcionado en Linux por el módulo del kerneltun). El conductor puede proporcionar:

ya sea una interfaz TAP de capa 2

Se comporta como un dispositivo Ethernet y se puede configurar como un puerto puente Ethernet: lo vnet5crea el hipervisor VM.
o una interfaz TUN de capa 3

No incluye información de trama (dirección MAC de Ethernet) ni maneja tramas, sino que trata solo con protocolos en la capa 3 o superior: IPv4 o IPv6. Por lo tanto, no se puede configurar como puerto puente Ethernet. Son OP tun0creados por OpenVPN en modo TUN.

OpenVPN también puede usar el modo TAP que podría conectarse en puente, pero esto requiere reconfigurar el control remoto.servidorlado también y todo el diseño de la red: el servidor remoto también sería parte de la LAN 192.168.1.0/24. OP no parece tener control sobre ello.

Entonces, consideremos lo que se puede hacer con la interfaz TUN del OP: esto se hará en la capa 3: enrutamiento, y no en la capa 2.

Reutilizar la configuración anterior solo para máquinas virtuales confiables

Si el host no incluye firewall avanzado, incluidas restricciones de firewall y/o alteraciones en la ruta del puente, no puede forzar a una VM a usarse como puerta de enlace: una VM con puente como antes puede simplemente ignorar el host y mantener 192.168.1.1 como puerta de enlace y que su tráfico no utilice la interfaz del host tun0al final.

Si se puede confiar en la VM y reconfigurarla, se puede seguir br0como se indicó anteriormente, aplicar cualquier configuración de OpenVPN basada en br0(reemplazando cualquier enp7s0referencia con br0) y hacer esto una vez que la VM se esté ejecutando (con la dirección 192.168.1.221) y la VPN esté activa:

en el anfitrión

Usandoenrutamiento basado en políticas/fuentepara seleccionar un resultado de ruta diferente para esta fuente específica:

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

Establecer como enrutador:

sysctl -w net.ipv4.ip_forward=1

Y en caso de que ninguna regla NAT similar ya resuelva este caso:

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

en VM (Linux), use el host como puerta de enlace en lugar del enrutador del host
```
ip route flush to default
ip route add default via 192.168.1.100
```

Recomendado para máquinas virtuales que no son de confianza: no configure la interfaz principal del host como puerto puente

Esto hace que sea más fácil controlar el tráfico de la VM tun0porque no tendrá vista de las partes de la red que no debe alterar.

cambiar la configuración de VM para usar su propia red IP

Ejemplo: 192.168.100.0/24 y una IP estática 192.168.100.2/24 (en lugar del DHCP de la red del host), con una puerta de enlace predeterminada 192.168.100.1. En una máquina virtual Linux:
```
ip address add 192.168.100.2/24 dev enp1s0
ip route add default via 192.168.100.1
```
En el host, comience desde la configuración inicial (sin puentes enp7s0)

Incluso se podría utilizar el puente cero a continuación (es decir, directamente ip address add 192.168.100.1/24 dev vnet5sin vnet5configurarlo como puerto puente), perolibvirtpodría hacer esto más difícil.

Simplemente tenga un puente dedicado para máquinas virtuales (aquí usando la dirección 192.168.100.1/24, aunque generalmentelibvirtproporciona un puente predeterminado virbr0con 192.168.122.1/24):
```
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
```
Y también usarenrutamiento de políticaspara cambiar el comportamiento del tráfico relacionado con las VM para las dos interfaces involucradas: br0y tun0. Como es habitual, implica algunas duplicaciones y modificaciones de rutas existentes en una tabla de enrutamiento alternativa. Aquí tun0se supone que solo se da servicio al host y sus máquinas virtuales. El objetivo final es: todo lo que viene del lado VM se enruta al lado tun, todo lo que viene del lado TUN se enruta al lado VM, sin tener en cuenta cualquier lado no necesario.
```
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
```
Nota: los paquetes entrantes tun0destinados al host (es decir, no enrutados) ya son manejados por ellocaltabla de enrutamiento y no necesita ninguna ruta adicional en la tabla 2000.

Establecer como enrutador:
```
sysctl -w net.ipv4.ip_forward=1
```
Luego complete con NAT ya que el servidor OpenVPN remoto no conoce 192.168.100.0/24:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
```

Si la VM aún debería poder alcanzar la LAN 192.168.1.0/24:

actualice nuevamente la tabla 2000 para acomodar esto

Duplicar la ruta LAN desde la tabla principal a la tabla 2000:
```
ip route add 192.168.1.0/24 dev enp7s0 table 2000
```
y agregue nuevamente una regla MASQUERADE adecuada

... ya que VM ahora está en una LAN diferente que otros sistemas no conocen:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
```
(Se podrían realizar la factorización de algunas reglas de iptables).

Configurando br0, sin VPN