Força pacotes TCP locais sobre o segmento de rede para captura

2

Eu tenho duas máquinas, A e B, rodando o RHEL Linux. Cada máquina tem uma placa de rede 1Gig conectada ao que eu chamo de rede "LAN". Cada máquina tem uma placa de rede 10Gig que está conectada ao que eu chamo de rede "BIGDATA". Essas redes não estão conectadas umas às outras, exceto por meio dessas máquinas.

Eu tenho conectores de fibra na interface 10Gig de A na rede BIGDATA. Os toques levam a um servidor de captura, onde eu quero gravar todos os dados entrando e saindo. Inicialmente, todo o TCP, mas talvez algum UDP seria bom no futuro.

Para fins de desenvolvimento e teste, quero executar ambos os lados de uma conversa TCP em A e ainda capturar a conversa com esses toques. Os desenvolvedores que usarão essa configuração não terão contas em B (pelo menos esse é meu objetivo).

Na minha opinião, deveria ser possível que um superusuário configurasse algum tipo de redirecionamento / redirecionamento em B, o que permitiria que um cliente em A se conectasse a um servidor em A, mas sobre a fibra derivada. Ou seja, o tráfego vai de A para B na rede LAN, depois de volta para A na rede BIGDATA. O tráfego de retorno leva o mesmo caminho de volta.

Minha tentativa até agora tem sido usar tunelamento ssh. Como A:~ $ssh B -L 8051:<A's-BIGDATA-IP>:3434 -N . Isso realmente funcionou muito bem para capturar o tráfego do cliente para o servidor. Mas, infelizmente, as respostas do servidor estão encontrando o atalho de apenas ficar local e nunca aparecer na fibra. Olhando para o wireshark, os pacotes conhecem o seu IP de destino e não se sentem obrigados a retomar o túnel.

Encontrei esta resposta, mas acredito que todos as soluções exigem que ambas as interfaces estejam na mesma rede. Talvez as sementes da minha solução estejam lá, mas não consigo encontrá-las.

Eu acho que eu poderia escrever isso do zero em C, fazendo um programa rodar em B para pegar conexões TCP na interface LAN, iniciar outra conexão TCP na interface BIGDATA, voltar para A e encaminhar as respostas também. Apenas copiaria a carga TCP, o que seria suficiente para os meus propósitos.

Existe uma ferramenta legal que já faz este encaminhamento / reencaminhamento?

Existe uma maneira de fazer o trabalho de tunelamento ssh da maneira que eu quero para o tráfego de retorno?

    
por RaveTheTadpole 15.08.2013 / 01:54

3 respostas

1

NAT de origem e destino

Você pode encaminhar o tráfego para fora e voltar com uma combinação de DNAT e SNAT usando a mesma ideia da resposta que você encontrou contanto que você não se importe em dividir os pacotes que está capturando. As capturas terão um destino ou src IP de B, mas parece que você já fez isso com seu cliente de encaminhamento. A vantagem do NAT seria a velocidade, eu acho, tudo fica no espaço do kernel.

Este exemplo é um cliente em A conectando-se a um servidor em A: BIGDATA: 3434. As regras NAT encaminham a conexão de A para B, então B encaminha de volta para A, enquanto configura a fonte como B para definir o caminho de retorno. Provavelmente, dê uma olhada no guia netfilter se você não estiver familiarizado com as tabelas NAT .

  • Verifique se o encaminhamento de IP está ativado em B com:

    sysctl -w net.ipv4.ip_forward=1
    echo 1 > /proc/sys/net/ipv4/ip_forward
    
  • o tráfego vai de A para B na rede LAN

    # On A, forward local traffic for local service out LAN to B.
    iptables -t nat -A OUTPUT -p tcp -d A:BIGDATA --dport 3434 -j DNAT --to-destination B:LAN
    
  • depois de volta para A na rede BIGDATA.

    # On B, forward the traffic to back to A over fibre
    iptables -t nat -A PREROUTING -p tcp -d B:LAN --dport 3434 -j DNAT --to-destination A:BIGDATA
    
  • O tráfego de retorno leva o mesmo caminho de volta

    # On B, set the source address for this traffic to B fibre
    iptables -t nat -A POSTROUTING -d A:BIGDATA -p tcp --dport 3434 -j SNAT --to-source B:BIGDATA
    

O rastreamento de conexão NAT cuida do último mapeamento de volta ao IP de origem original.

    
por 19.08.2013 / 12:15
1

Dê uma olhada em EtherPuppet , possivelmente em combinação com Scapy ; EtherPuppet é descrito como

a small program for Linux that will create a voodoo doll for an Ethernet interface.

...

everything seen by the real interface will be seen by the virtual one. Everything that will be sent to the virtual interface will be emitted by the real one.

Scapy é descrito como

a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more.

    
por 15.08.2013 / 04:59
0

Embora não seja a resposta que eu esperava encontrar, acabei por mudar a minha.

Eu escrevi um programa para rodar em B que aceitaria conexões na interface LAN e iniciaria conexões fora da interface BIGDATA. O programa copia a carga TCP para as novas mensagens de saída. Ele faz o mesmo com as respostas voltando para o outro lado. Isso não preserva as informações do cabeçalho (por exemplo, IP de origem) - no meu caso, acho que isso é bom, para que o tráfego de retorno não atinja.

Está funcionando, embora tenha sido uma dor para algo que eu considero tão básico. Eu colocaria a fonte, mas é muito prolixa e provavelmente não muito bem escrita.

Vou deixar respostas inaceitáveis, na esperança de que alguém acabe encontrando a solução perfeita!

    
por 18.08.2013 / 19:03