Configurando br0, sem VPN

Question

Existem duas questões na mesma questão e, na verdade, não dependem uma da outra. Ainda responderei ambos.

Além disso, a noprefixrouteopção de endereço indica que parte da configuração da rede é gerenciada por alguma ferramenta adicional (como NetworkManager) para adicionar rotas. Esta resposta não tentará lidar com a integração em ferramentas de rede. Isso inclui lidar com a configuração do DHCP, que pode substituir as alterações posteriormente se não for reconfigurada corretamente. Muitas configurações desaparecem quando a interface é desativada ou excluída e precisam ser feitas novamente, portanto, é melhor fazer isso em vários ganchos de várias ferramentas de rede responsáveis.

Configurando `br0`, sem VPN

Uma interface definida como porta bridge perde sua participação no roteamento

Uma vez definida como porta de ponte, as rotas associadas à interface são ignoradas. Ainda podem existir efeitos colaterais prejudiciais ao deixar o endereço nele. Detalhes podem ser encontrados no blogIsolamento adequado de uma ponte Linux:

entregue a moldura ao específico do dispositivomanipulador de recebimento, caso existam,

entregar o quadro para um global ou específico do dispositivomanipulador de protocolo(por exemplo, IPv4, ARP, IPv6).

Para uma interface em ponte,o kernel configurou um manipulador de recebimento específico do dispositivo, br_handle_frame(). Esta função não permitirá nenhum processamento adicional no contexto da interface de entrada, exceto para quadros STP e LLDP, ou se o “brouting” estiver habilitado. Portanto,o manipuladores de protocolo nunca são executadosnesse caso.

O endereço IP definido em uma interface que se tornou uma porta de ponte deve ser movido para a própria interface da ponte especial ( br0: a própria ponte), que é a única capaz de participar do roteamento (existem outras opções, mas vamos simplificar). O mesmo se aplica às rotas relevantes.

Suponhamos que o gateway padrão do OP seja 192.168.1.1/24. Vamos reescrever isso para o primeiro 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

Com isso, tanto o host quanto a VM podem acessar a Internet.

Observe que para a parte VM, vnet5também é uma porta bridge e também não participa do roteamento. O host está apenas alternando quadros entre VM e roteador (192.168.1.1): nenhum roteamento envolvido.

Com VPN e a `tun0`interface

OpenVPN depende do driver TUN/TAP (fornecido no Linux pelo módulo do kerneltun). O motorista pode fornecer:

ou uma interface TAP de camada 2

Ele se comporta como um dispositivo Ethernet e pode ser configurado como uma porta ponte Ethernet: criada vnet5pelo hipervisor VM.
ou uma interface TUN de camada 3

Não inclui informações de quadro (endereço MAC Ethernet) nem lida com quadros, mas lida apenas com protocolos na camada 3 ou acima: IPv4 ou IPv6. Portanto, não pode ser definida como uma porta ponte Ethernet. Esses são os OPs tun0criados pelo OpenVPN no modo TUN.

OpenVPN também pode usar o modo TAP que pode ser conectado em ponte, mas isso requer reconfigurar o controle remotoservidorlado também e todo o layout da rede: o servidor remoto também faria parte da LAN 192.168.1.0/24. OP não parece ter controle sobre isso.

Então vamos considerar o que pode ser feito com a interface TUN do OP: isso será feito na camada 3: roteamento, e não na camada 2.

Reutilizando a configuração anterior somente para VMs confiáveis

Se o host não incluir firewall avançado, incluindo restrições de firewall e/ou alterações no caminho da ponte, ele não poderá forçar uma VM a se usar como gateway: uma VM com ponte como anteriormente pode simplesmente ignorar o host e manter 192.168.1.1 como gateway e fazer com que seu tráfego não utilize a interface do host tun0no final.

Se a VM puder ser confiável e reconfigurada, pode-se manter br0como acima, aplicar qualquer configuração OpenVPN baseada em br0(substituindo qualquer enp7s0referência por br0) e fazer isso quando a VM estiver em execução (com endereço 192.168.1.221) e a VPN estiver ativa:

no anfitrião

Usandoroteamento baseado em política/fontepara selecionar um resultado de rota diferente para esta origem 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

Definir como roteador:

sysctl -w net.ipv4.ip_forward=1

E caso nenhuma regra NAT semelhante já lide com este caso:

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

na VM (Linux), use o host como gateway em vez do roteador do host

ip route flush to default
ip route add default via 192.168.1.100

Recomendado para VMs não confiáveis: não defina a interface principal do host como porta de ponte

Isso torna mais fácil impor o tráfego da VM tun0porque ela não terá visualização das partes da rede que não deve adulterar.

alterar as configurações da VM para usar sua própria rede IP

Exemplo: 192.168.100.0/24 e um IP estático 192.168.100.2/24 (em vez do DHCP da rede do host), com gateway padrão 192.168.100.1. Em uma VM Linux:
```
ip address add 192.168.100.2/24 dev enp1s0
ip route add default via 192.168.100.1
```
No host, comece a partir da configuração inicial (sem ponte enp7s0)

Pode-se até fazer com a ponte zero abaixo (ou seja: diretamente ip address add 192.168.100.1/24 dev vnet5sem vnet5definir como porta da ponte), maslibvirtpode tornar isso mais difícil.

Basta ter uma bridge dedicada para VMs (aqui usando o endereço 192.168.100.1/24, embora normalmentelibvirtfornece uma ponte padrão virbr0com 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
```
E também usarroteamento de políticaalterar o comportamento do tráfego relacionado à(s) VM(s) para as duas interfaces envolvidas: br0e tun0. Como sempre, envolve algumas duplicações e alterações de rotas existentes em uma tabela de roteamento alternativa. Aqui tun0presume-se que atenda apenas o host e sua(s) VM(s). O objetivo final é: tudo o que vem do lado da VM é roteado para o lado do tun, tudo o que vem do lado do TUN é roteado para o lado da VM, desconsiderando qualquer lado não necessário.
```
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: os pacotes recebidos tun0destinados ao host (ou seja: não roteados) já são tratados pelolocaltabela de roteamento e não precisa de nenhuma rota adicional na tabela 2000.

Definir como roteador:
```
sysctl -w net.ipv4.ip_forward=1
```
Em seguida, complete com NAT, pois o servidor OpenVPN remoto não conhece 192.168.100.0/24:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
```

Se a VM ainda conseguir acessar a LAN 192.168.1.0/24:

atualize novamente a tabela 2000 para acomodar isso

Duplique a rota LAN da tabela principal para a tabela 2000:
```
ip route add 192.168.1.0/24 dev enp7s0 table 2000
```
e adicione novamente uma regra MASQUERADE adequada

... já que a VM agora está em uma LAN diferente que outros sistemas não conhecem:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
```
(Algumas fatorações de regras do iptables poderiam ser feitas).

Answer 1

Existem duas questões na mesma questão e, na verdade, não dependem uma da outra. Ainda responderei ambos.

Além disso, a noprefixrouteopção de endereço indica que parte da configuração da rede é gerenciada por alguma ferramenta adicional (como NetworkManager) para adicionar rotas. Esta resposta não tentará lidar com a integração em ferramentas de rede. Isso inclui lidar com a configuração do DHCP, que pode substituir as alterações posteriormente se não for reconfigurada corretamente. Muitas configurações desaparecem quando a interface é desativada ou excluída e precisam ser feitas novamente, portanto, é melhor fazer isso em vários ganchos de várias ferramentas de rede responsáveis.

Configurando `br0`, sem VPN

Uma interface definida como porta bridge perde sua participação no roteamento

Uma vez definida como porta de ponte, as rotas associadas à interface são ignoradas. Ainda podem existir efeitos colaterais prejudiciais ao deixar o endereço nele. Detalhes podem ser encontrados no blogIsolamento adequado de uma ponte Linux:

entregue a moldura ao específico do dispositivomanipulador de recebimento, caso existam,

entregar o quadro para um global ou específico do dispositivomanipulador de protocolo(por exemplo, IPv4, ARP, IPv6).

Para uma interface em ponte,o kernel configurou um manipulador de recebimento específico do dispositivo, br_handle_frame(). Esta função não permitirá nenhum processamento adicional no contexto da interface de entrada, exceto para quadros STP e LLDP, ou se o “brouting” estiver habilitado. Portanto,o manipuladores de protocolo nunca são executadosnesse caso.

O endereço IP definido em uma interface que se tornou uma porta de ponte deve ser movido para a própria interface da ponte especial ( br0: a própria ponte), que é a única capaz de participar do roteamento (existem outras opções, mas vamos simplificar). O mesmo se aplica às rotas relevantes.

Suponhamos que o gateway padrão do OP seja 192.168.1.1/24. Vamos reescrever isso para o primeiro 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

Com isso, tanto o host quanto a VM podem acessar a Internet.

Observe que para a parte VM, vnet5também é uma porta bridge e também não participa do roteamento. O host está apenas alternando quadros entre VM e roteador (192.168.1.1): nenhum roteamento envolvido.

Com VPN e a `tun0`interface

OpenVPN depende do driver TUN/TAP (fornecido no Linux pelo módulo do kerneltun). O motorista pode fornecer:

ou uma interface TAP de camada 2

Ele se comporta como um dispositivo Ethernet e pode ser configurado como uma porta ponte Ethernet: criada vnet5pelo hipervisor VM.
ou uma interface TUN de camada 3

Não inclui informações de quadro (endereço MAC Ethernet) nem lida com quadros, mas lida apenas com protocolos na camada 3 ou acima: IPv4 ou IPv6. Portanto, não pode ser definida como uma porta ponte Ethernet. Esses são os OPs tun0criados pelo OpenVPN no modo TUN.

OpenVPN também pode usar o modo TAP que pode ser conectado em ponte, mas isso requer reconfigurar o controle remotoservidorlado também e todo o layout da rede: o servidor remoto também faria parte da LAN 192.168.1.0/24. OP não parece ter controle sobre isso.

Então vamos considerar o que pode ser feito com a interface TUN do OP: isso será feito na camada 3: roteamento, e não na camada 2.

Reutilizando a configuração anterior somente para VMs confiáveis

Se o host não incluir firewall avançado, incluindo restrições de firewall e/ou alterações no caminho da ponte, ele não poderá forçar uma VM a se usar como gateway: uma VM com ponte como anteriormente pode simplesmente ignorar o host e manter 192.168.1.1 como gateway e fazer com que seu tráfego não utilize a interface do host tun0no final.

Se a VM puder ser confiável e reconfigurada, pode-se manter br0como acima, aplicar qualquer configuração OpenVPN baseada em br0(substituindo qualquer enp7s0referência por br0) e fazer isso quando a VM estiver em execução (com endereço 192.168.1.221) e a VPN estiver ativa:

no anfitrião

Usandoroteamento baseado em política/fontepara selecionar um resultado de rota diferente para esta origem 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

Definir como roteador:

sysctl -w net.ipv4.ip_forward=1

E caso nenhuma regra NAT semelhante já lide com este caso:

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

na VM (Linux), use o host como gateway em vez do roteador do host

ip route flush to default
ip route add default via 192.168.1.100

Recomendado para VMs não confiáveis: não defina a interface principal do host como porta de ponte

Isso torna mais fácil impor o tráfego da VM tun0porque ela não terá visualização das partes da rede que não deve adulterar.

alterar as configurações da VM para usar sua própria rede IP

Exemplo: 192.168.100.0/24 e um IP estático 192.168.100.2/24 (em vez do DHCP da rede do host), com gateway padrão 192.168.100.1. Em uma VM Linux:
```
ip address add 192.168.100.2/24 dev enp1s0
ip route add default via 192.168.100.1
```
No host, comece a partir da configuração inicial (sem ponte enp7s0)

Pode-se até fazer com a ponte zero abaixo (ou seja: diretamente ip address add 192.168.100.1/24 dev vnet5sem vnet5definir como porta da ponte), maslibvirtpode tornar isso mais difícil.

Basta ter uma bridge dedicada para VMs (aqui usando o endereço 192.168.100.1/24, embora normalmentelibvirtfornece uma ponte padrão virbr0com 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
```
E também usarroteamento de políticaalterar o comportamento do tráfego relacionado à(s) VM(s) para as duas interfaces envolvidas: br0e tun0. Como sempre, envolve algumas duplicações e alterações de rotas existentes em uma tabela de roteamento alternativa. Aqui tun0presume-se que atenda apenas o host e sua(s) VM(s). O objetivo final é: tudo o que vem do lado da VM é roteado para o lado do tun, tudo o que vem do lado do TUN é roteado para o lado da VM, desconsiderando qualquer lado não necessário.
```
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: os pacotes recebidos tun0destinados ao host (ou seja: não roteados) já são tratados pelolocaltabela de roteamento e não precisa de nenhuma rota adicional na tabela 2000.

Definir como roteador:
```
sysctl -w net.ipv4.ip_forward=1
```
Em seguida, complete com NAT, pois o servidor OpenVPN remoto não conhece 192.168.100.0/24:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
```

Se a VM ainda conseguir acessar a LAN 192.168.1.0/24:

atualize novamente a tabela 2000 para acomodar isso

Duplique a rota LAN da tabela principal para a tabela 2000:
```
ip route add 192.168.1.0/24 dev enp7s0 table 2000
```
e adicione novamente uma regra MASQUERADE adequada

... já que a VM agora está em uma LAN diferente que outros sistemas não conhecem:
```
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
```
(Algumas fatorações de regras do iptables poderiam ser feitas).

Configurando br0, sem VPN