Enquanto brincava com um convidado do qemu descobri algo muito peculiar. Se eu configurar o firewall do sistema para rejeitar todo o tráfego para meu gateway ( 10.0.2.2), o firewall somente rejeitará o tráfego destinado diretamente ao gateway. O tráfego não destinado a 10.0.2.2aparentemente continua a ser roteado e flui pelo gateway como se a regra não estivesse lá.
Pelo que entendi do ponto de vista do hóspede ( 10.0.2.15):
Packet{dest==10.0.2.0/24} 10.0.2.15 -x-> 10.0.2.2 (Rejected)
Packet{dest!=10.0.2.0/24} 10.0.2.15 <--> 10.0.2.2 <-> !=10.0.2.0/24 (Okay)
Isso é completamente contrário ao que eu esperava. Eu suponho que há algo que estou perdendo, mas não sei o quê.
Aqui está minha configuração:
- Regra de firewall:
ufw reject out to 10.0.2.0/24 - Saída de
ip route:default via 10.0.2.2 dev ens3 proto dhcp metric 100 10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15 metric 100 - A parte relevante da saída de
iptables -Sparece ser:-A ufw-user-output -d 10.0.2.0/24 -j REJECT --reject-with icmp-port-unreachable
Isso está funcionando e não está bloqueado porque um gateway roteia pacotes com endereços IP de origem e destino que não são o endereço do gateway. Nenhum pacote IPv4 (veja mais adiante sobre ARP) com endereço 10.0.2.2 é usado para rotear com sucesso através do gateway com endereço IP 10.0.2.2/24.
Então quando 10.0.2.15 envia um pacote para 8.8.8.8 este pacote tem origem 10.0.2.15 e destino 8.8.8.8. Este pacote não tem destino 10.0.2.2 e, portanto, nenhum destino dentro de 10.0.2.0/24: pass.
Os únicos pacotes com o endereço IPv4 10.0.2.2 em sua carga útil indiretamente envolvidos no roteamento pelo gateway não são pacotes IPv4. São pacotes ARP usados pelo sistema VM para descobrir (e armazenar em cache em sua tabela ARP) o endereço MAC Ethernet da interface do gateway. Tráfego IPv4 para "fora": combinando a rota com o gateway, é então enviado na camada de enlace (Ethernet) para este endereço MAC (e não para o endereço IP 10.0.2.2).
O ARP não é filtrado pelo iptables , que é o backend do UFW, portanto, não pode ser bloqueado com o UFW. Pode ser com arptables , por exemplo, mas casos de uso úteis não são muito comuns.
Notas
DHCP (IPv4)
Se 10.0.2.2 também for um servidor DHCP para as VMs, isso pode ou não (dependendo da tecnologia exata em uso) impedir em algum momento posterior a comunicação DHCP para funcionar corretamente ou forçar a VM a fazer uma transmissão DHCP DISCOVER em vez de um unicast SOLICITAÇÃO DE DHCP. Se a concessão fosse perdida possivelmente algumas horas depois, o mesmo aconteceria com o endereço IP e, portanto, as rotas e, portanto, indiretamente a conectividade através do roteador.
Normalmente esse não é o caso, porque geralmente o DHCP no Linux tem que depender de soquetes RAW (por exemplo, para manipular o endereço de origem 0.0.0.0 corretamente) que ignoram todas as regras do iptables .
IPv6
Como o protocolo de resolução da camada de enlace para IPv6 não é ARP, mas sim ICMPv6 , portanto parte do IPv6 e filtrado por ip6tables , algumas suposições válidas para IPv4 não são válidas para IPv6. Por exemplo, bloquear indiscriminadamente o ICMPv6 geralmente resulta em perda muito rápida de conectividade IPv6 e remoção do endereço IPv6 roteável adquirido através do SLAAC , enquanto o bloqueio indiscriminado de ICMP para IPv4 geralmente funciona bem (além de possíveis problemas de blackhole PMTUD ).