Estou configurando o host de virtualização KVM com roteamento baseado em política (rede de gerenciamento 192.168.1.0/24 para tráfego relacionado ao host, como atualizações, ssh etc, 192.168.2.0/24 rede DMZ roteada para VMs)
A configuração é assim (por ^^^ eu quero dizer como acima para representar a estrutura da árvore)
#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
máquinas estão em um "switch", Bn no segundo, etc. O host se comporta como roteador e tem o iptables instalado. O ip de origem é validado por bridge no nível do iptables.
Em geral, tudo que é "normal" funciona, mas quando estou executando algumas operações de caso de borda, ele ainda se comporta como deveria, mas os logs sugerem que é mais coincidência do que funcionamento correto real. Por exemplo:
conectando-se ao 192.168.1.3 da VM (host diferente na rede de gerenciamento) que é operação bloqueada no nível do iptables (tcp-reset) fornece
(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
observe que a interface OUT está correta de acordo com o que deve ser feito considerando a lógica de separação de rede host / guest e, mesmo que tais pacotes sejam encaminhados pelo host, eles serão descartados no firewall. No entanto, o iptables do host não pode ser rejeitado corretamente com o tcp-reset, de modo que tais conexões apenas ficam pendentes na VM e não recebem reset
conectando-se ao 192.168.1.9 da VM fornece
IPv4: martian source 192.168.1.9 from 10.0.1.2 on dev brguestA
e nada mais. Trocar lugares de 10.0.1.xe 192.168.1.x nesses logs me deixa muito confuso e eu realmente não entendo qual é o significado daqueles (quais são src ip e qual deles é dst ip). Eu realmente não sei o que o host está tentando fazer e porque ele falha. Aqui está a saída do meu ip rule e 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
# ...
Estou usando systemd-networkd para gerenciamento de rede. pensei que está acontecendo porque o host sempre tenta responder usando brhost device como sendo OUTPUT tipo de pacote que tem iif definido como lo , por isso ele é detectado pela regra from iif lookup host . No entanto, não parece ser um caso, pois a conexão com 192.168.2.4 é rejeitada corretamente, de modo que nem sempre escolha brhost como fonte de saída.