Corrupção de porta usando o iptables NAT no Enterprise Linux 6

1

Estou tentando configurar um redirecionamento de portal da web cativo no CentOS usando a seguinte configuração:

Essa configuração funciona para os primeiros poucos pacotes, mas, de repente, a porta de destino é corrompida na resposta do servidor. O rastreamento de pacotes é assim:

Cliente: o host que faz a solicitação da web original. Servidor: destino original para o pedido Portal: servidor de portal cativo

Esse rastreamento de pacote é obtido de um local que pode ver o tráfego do cliente e do portal. Linhas que começam com c: são do lado do cliente e p: são do lado do portal.

c: client:57877 -> server:80 [SYN]
p: client:1092 -> portal:80 [SYN]  NAT adjusted SYN
p: portal:80 -> client:1092 [SYN, ACK]
c: server:80 -> client:57877 [SYN, ACL] NAT reversed on the SYN/ACK
c: client:57877 -> server:80 [ACK]
c: client:57877 -> server:80 HTTP GET
p: client:1092 -> portal:80 [ACK]
p: client:1092 -> portal:80 HTTP GET
p: portal:80 -> client:1092 [ACK]
c: server:68 -> client:57877 [ACK]
          ^^ WTF?!?

Neste ponto, a conexão é feita. O cliente não está esperando um pacote nessa porta e envia um RST. O número da porta quebrado é incrementado em 1 sempre que essa conexão é tentada (presumivelmente, funcionará uma vez a partir de 12 tentativas). Todas as retransmissões têm o mesmo número de porta quebrado na resposta. Não tenho ideia do que poderia estar causando isso.

Isso é um bug ou estou fazendo algo errado? Esta máquina tem uma configuração um pouco incomum. Está configurado como uma ponte. Para aplicar somente a regra NAT aos pacotes em uma única direção, os pacotes são marcados com uma regra NAT ebtables primeiro, e essa marca é verificada quando o NAT iptables é aplicado.

Isso está no Enterprise Linux 6 com Kernel 2.6.32-279.5.2.el6.x86_64

A regra NAT é:

target     prot opt in     out     source               destination         
DNAT       tcp  --  ilb    any     anywhere             anywhere            multiport dports http,https mark match 0x8 to:<portal IP>

ilb é a ponte.

    
por Jason Andresen 12.01.2014 / 20:47

0 respostas