Estoy configurando un host de virtualización KVM con enrutamiento basado en políticas (red de administración 192.168.1.0/24 para tráfico relacionado con el host como actualizaciones, ssh, etc., red DMZ 192.168.2.0/24 enrutada a máquinas virtuales)
La configuración se ve así (por ^^^ quiero decircomo arribapara representar la estructura del árbol)
#external connectivity
eth0 -> vlan110 -> brhost (192.168.1.9)
^^^ -> vlan120 -> brguest (192.168.2.4)
#internal connectivity
brguestA (10.0.1.1) -> tapA0
^^^ -> tapA1
^^^ -> tapA2
brguestB (10.0.2.1) -> tapB0
^^^ -> tapB1
# ... and so on for each VM group subnet
Las máquinas An están en un "interruptor", Bn en el segundo, etc. El host se comporta como un enrutador y tiene iptables instalado. La IP de origen se valida por puente en el nivel de iptables.
En general, todo lo "normal" funciona, pero cuando realizo algunas operaciones de casos fronterizos todavía se comporta como debería, pero los registros sugieren que es más una coincidencia que un funcionamiento adecuado real. Por ejemplo:
conectarse a 192.168.1.3 desde VM (host diferente en la red de administración) que está bloqueada la operación en el nivel de iptables (tcp-reset) proporciona
(iptables reject log) IN=brguestA OUT=brguest SRC=10.0.1.2 DST=192.168.1.3 ... IPv4: martian source 10.0.1.2 from 192.168.1.3 on dev brhost
tenga en cuenta que OUTla interfaz es realmente correcta de acuerdo con lo que debería hacer considerando la lógica de separación de la red host/invitado e incluso si dichos paquetes fueran reenviados por el host, de todos modos se colocarían en el firewall. Sin embargo, las iptables del host no pueden rechazarse correctamente con tcp-reset, por lo que dichas conexiones simplemente se bloquean en la VM y no se restablecen.
conectarse a 192.168.1.9 desde VM proporciona
IPv4: martian source 192.168.1.9 from 10.0.1.2 on dev brguestA
y nada más. Intercambiar lugares de 10.0.1.x y 192.168.1.x en esos registros me confunde mucho y realmente no entiendo qué significan (cuáles son src ip y cuál es dst ip). Realmente no sé qué intenta hacer el host y por qué falla. Aquí está el resultado de mi ip ruley ip route:
ip rule
0: from all lookup local
32763: from 10.0.0.0/16 lookup guest
32764: from 192.168.2.0/24 lookup guest
32765: from all iif lo lookup host
32766: from all lookup main
32767: from all lookup default
ip route show table host
default via 192.168.1.1 dev brhost proto static
192.168.1.0/24 dev brhost proto static
ip route show table guest
default via 192.168.2.1 dev brguest proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ... so on for other networks
ip route show table main
192.168.1.0/24 dev brhost proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ...
Lo estoy usando systemd-networkdpara la gestión de red. IpensamientoEsto sucede porque el host siempre intenta responder utilizando brhostel dispositivo como el OUTPUTtipo de paquete que ha iifconfigurado lopara que quede atrapado por from iif lookup hostla regla. Sin embargo, no parece ser el caso, ya que la conexión 192.168.2.4se rechaza correctamente, por lo que no siempre se selecciona brhostcomo fuente de salida.