Início / computer / Perguntas / 1847170
Accepted
Nykau
Asked: 2024-06-26 23:19:44 +0800 CST

nftables não captura um pacote que já viu

  • 772

Eu configurei uma rede local segmentada, onde cada segmento é VLAN e o switch na raiz de todas as VLANs também atua como roteador entre todos os segmentos IP/VLAN (o switch é o Dell S4810 executando DNOS 9.14). gateway para a Internet e o endereço IP local do gateway da Internet é o endereço IP do gateway padrão do S4810. Antes de encaminhar pacotes para o exterior, aplica-se SNAT (masquerade) para que o pacote encaminhado para a Internet tenha como endereço de origem o endereço público do roteador padrão. Nada sofisticado aqui. Quase tudo parece funcionar conforme o esperado: um nó em qualquer segmento pode entrar em contato com outros nós em outros segmentos, todos eles podem acessar a Internet e obter uma resposta, e os nós fora desta LAN veem o endereço IP de origem mascarado correto.

As coisas ficam complicadas quando a máquina de gateway da Internet (NÃO o S4810) também executa VMs com Proxmox. Esta máquina executa o Debian 12.5 e é configurada com interfaces VLAN sobre a física que vai para o S4810, e as próprias interfaces VLAN são agrupadas em pontes, uma por VLAN. A interface para a internet também está envolvida em sua própria ponte. Eu uso pontes para que o Proxmox VM possa usá-las para conectar-se a qualquer uma das redes. Quando uma VM rodando nesta máquina com uma interface virtual na ponte da Internet, ela pode acessar a Internet corretamente, mas com um endereço IP de origem que não precisa de SNAT e não é SNAT.

Quando outra VM com uma interface virtual em uma das interfaces/pontes da VLAN, ela pode alcançar outras máquinas na VLAN correspondente. Além disso, qualquer máquina em segmentos VLAN consegue acessar a Internet usando o S4810 como gateway padrão sem problemas, incluindo VM, desde que não sejam executadas no gateway de Internet/hipervisor Proxmox, mas em qualquer outra máquina hipervisor Proxmox. No entanto, quando uma VM em execução no gateway de Internet/hipervisor Proxmox deseja acessar a Internet por meio de uma das VLANs, ela não consegue. Assim como outras máquinas que funcionam conforme esperado, a VM está configurada para usar o S4810 como gateway padrão. O S4810 redireciona para o gateway de Internet/hipervisor Proxmox qualquer um dos pacotes destinados à Internet que dele recebe, e esse gateway deve encaminhar o pacote com mascaramento.

Posso ver os pacotes indo para o S4810, posso ver o S4810 enviando de volta o pacote para o gateway da Internet, posso ver o pacote duas vezes tsharkno gateway da Internet (uma vez com ttl 64, a segunda vez com ttl 62, ou seja, após o segundo roteamento ser executada), mas a tabela nftablesde nat postrouting(prioridade srcnat) parece capturá-la apenas uma vez, com ttl 64, ou seja, antes de ser enviada para qualquer lugar e antes que o mascaramento precise ser aplicado. Quando o pacote está de volta e o mascaramento precisa ser aplicado, parece que nftablesnão o vê, conforme afirmado com meta nftrace set 1a regra no topo da tabela e o comando nat postroutingcorrespondente . nft monitor traceComo resultado, o mascaramento não é aplicado e o nó externo que recebe o pacote o recebe com o endereço de origem não SNAT e não pode enviar uma resposta.

Existe tal recurso nftablesque aceitaria ver um determinado pacote apenas uma vez? Se sim, como posso desativá-lo para aplicar a máscara no momento certo? Ou é algo totalmente diferente que acontece? Ficarei feliz em fornecer qualquer registro ou captura necessária para me ajudar a solucionar o problema.

debian

1 respostas

  1. Best Answer

    É um recurso especificamente no natgancho 1 do Netfilter , tanto do iptables quanto do nftables.

    O NAT do Linux é stateful, pois tem os requisitos de que, por exemplo, cada pacote pertencente ao mesmo fluxo seja SNAT para o mesmo endereço de origem:porta (mesmo que as condições que influenciariam a escolha da porta mudem no meio do fluxo) e, claro que os pacotes de resposta seriam corretamente não NAT.

    Por causa disso, o estado NAT é lembrado por estado conntrack (o mesmo conntrack que rastreia estados "novos, relacionados e estabelecidos" para suas regras de filtro). Somente o primeiro pacote de um fluxo passa pelas natregras; depois que snat/ dnat/ masqueradefoi - ou não - aplicado ao primeiro pacote, as decisões NAT são armazenadas no conntrack e aplicadas automaticamente a todos os pacotes subsequentes que correspondam a esse estado do conntrack, o que significa que esses pacotes não passam mais pelos natganchos 1 para que eles não receberá NAT duplo.

    (Você pode ver os estados em conntrack -L.)

    Se você tiver uma configuração particularmente estranha, onde os mesmos pacotes passam duas vezes pelo mesmo roteador (no mesmo namespace de rede), meu primeiro pensamento é que eles não deveriam ser roteados duas vezes pelo mesmo roteador. (Suponho que você possa ter "aplicar regras de iptables a pacotes em ponte" ativado?)

    Deveria ser possível contornar isso marcando explicitamente esses pacotes como "não rastreados" em uma cadeia suficientemente precoce quando eles passarem pelo seu conjunto de regras pela primeira vez, de modo que eles não toquem no conntrack (ou NAT) até que voltem para sua segunda viagem.

    table inet foo {
    chain prerouting {
        type filter hook prerouting priority -300;
        # This should match the first group of packets but not the second
        iifname foo oifname bar notrack
    }
}

    Alternativamente, tente o (relativamente novo) recurso de zona conntrackct zone set XXX - (na mesma cadeia onde você usaria notrack) parece permitir marcar os pacotes como pertencentes a fluxos distintos, o que seria um método muito melhor do que notrack se funcionar.

    Como alternativa, divida as duas configurações em namespaces de rede diferentes.

    1 O nome da tabela em nftables é irrelevante – apenas a configuração por cadeia type nat hook ...decide quando os pacotes passam pela cadeia.

    • 1

relate perguntas