Página 1 de 2 12 ÚltimoÚltimo
+ Responder ao Tópico



  1. Boa noite,

    Em primeiro lugar queria dizer que nao entendo muito de iptables, mas com a necessidade de fazer funcionar somada ao google consegui fazer alguma coisa, porém não foi suficiente.

    Num PC de uma filial (10.1.10.100/16) tenho uma aplicacao que escuta a porta 3000.
    Daqui da matriz (172.20.0.0/21) preciso conseguir me conectar nessa maquina, na porta citada.
    Na entrada da conexao da filial temos um iptables.
    Da matriz eu tenho rota até o firewall da filial, mas pra rede interna não.

    Solução proposta: redirecionar a porta 3000 do firewall (onde eu tenho rota) para a porta 3000 da estação que roda a aplicação.

    A partir do firewall eu consigo dar um telnet na porta 3000 da maquina com a aplicação.

    A partir da matriz o telnet não rola.

    Escutando a interface interna do firewall com tcpdump consegui ver que o handshake nao está se completando. O PC com a aplicação recebe o 1o SYN, envia o SYN-ACK e logo dps recebe outro "1o SYN", o que o faz enviar um RST e recomeçar a negociação.

    Código :
    fw:/etc/init.d# tcpdump -i eth0 | grep 10.1.10.100
    tcpdump: listening on eth0
    12:03:26.488851 172.20.3.248.2141 > 10.1.10.100.3000: S 1298900677:1298900677(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
    12:03:26.497035 10.1.10.100.3000 > 172.20.3.248.2141: S 0:0(0) ack 1298900678 win 255 (DF)
    12:03:29.417553 172.20.3.248.2141 > 10.1.10.100.3000: S 1298900677:1298900677(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
    12:03:29.425558 10.1.10.100.3000 > 172.20.3.248.2141: R 1:1(0) win 65535 (DF)
    12:03:35.341321 172.20.3.248.2141 > 10.1.10.100.3000: S 1298900677:1298900677(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
    12:03:35.349499 10.1.10.100.3000 > 172.20.3.248.2141: S 0:0(0) ack 1298900678 win 255 (DF)
    12:04:35.150773 10.1.10.100.3000 > 172.20.3.248.2141: R 1:1(0) win 255 (DF)
    Minhas regras estão assim:
    Código :
    iptables -t filter -A INPUT -p tcp --dport 3000 -j ACCEPT
    iptables -t filter -A FORWARD -p tcp --sport 3000 -j ACCEPT
    iptables -t filter -A FORWARD -p tcp --dport 3000 -j ACCEPT
    iptables -t nat -A PREROUTING -d 10.9.0.2 -p tcp --dport 3000 -i eth1 -j DNAT --to 10.1.10.100
    iptables -t nat -A POSTROUTING -s 10.1.10.100 -p tcp --sport 3000 -j SNAT --to 172.20.3.248
    Onde:
    10.9.0.2: interface EXTERNA do firewall (não passa pela internet, por isso o ip invalido)
    172.20.3.248: meu computador, que estou usando para fazer os testes... se funcionar para UM ip já está bom, mas o ideal seria liberar para 172.20.0.0/21
    10.1.10.100: host com a porta 3000 aberta

    Tenho o mesmo resultado sem a linha do SNAT, que eu desconfio ser a causadora do problema, mas sinceramente estou de maos atadas.

    Existem outras regras neste iptables, mas mesmo derrubando TODAS e rodando apenas as regras acima descritas o resultado é sempre o mesmo e o handshake nao se completa.

    Se puderem ajudar, ficarei muito grato.

    PS: desculpem pelo post grande, mas sem informações eu sei que fica dificil receber ajuda....

  2. Cara, não seria mais fácil criar uma rota pra esse destino já que não tem nat no meio??



  3. Citação Postado originalmente por Magnun Ver Post
    Cara, não seria mais fácil criar uma rota pra esse destino já que não tem nat no meio??
    Obrigado pela sugestao, mas tenho outras filiais que usam em suas redes internas a mesma classe de rede desta filial, portanto eu nao conseguiria ter uma rota direto pra 10.1.10.100

  4. Então na filial o FW também está fazendo nat??
    A estrutura é mais ou menos assim:

    A regra de SNAT não é necessária. Como o seu linux com iptables é o gateway daquela rede quando ele rotear esse pacote ele desfaz o DNAT e devolve o pacote como origem sendo ele mesmo...

    Se você observar, na segunda linha do tcpdump, qual a porta de destino do pacote que ta indo pro linux?? 2141. Provavelmente esse pacote está sendo dropado... Adiciona um INPUT pra pacotes acima de 1024 ou então com porta de origem 3000. Acho que talvez seja isso, como o destino não recebe o ack ele ocorre um timeout e a conexão se reinicia com o envio de um novo syn...

    Qualquer coisa posta ai...



  5. Citação Postado originalmente por Magnun Ver Post
    Então na filial o FW também está fazendo nat??
    A estrutura é mais ou menos assim:

    A regra de SNAT não é necessária. Como o seu linux com iptables é o gateway daquela rede quando ele rotear esse pacote ele desfaz o DNAT e devolve o pacote como origem sendo ele mesmo...

    Se você observar, na segunda linha do tcpdump, qual a porta de destino do pacote que ta indo pro linux?? 2141. Provavelmente esse pacote está sendo dropado... Adiciona um INPUT pra pacotes acima de 1024 ou então com porta de origem 3000. Acho que talvez seja isso, como o destino não recebe o ack ele ocorre um timeout e a conexão se reinicia com o envio de um novo syn...

    Qualquer coisa posta ai...
    Mesmo mudando a regra padrao de INPUT, OUTPUT e FORWARD pra ACCEPT o problema permanece o mesmo.

    Eu sinceramente travei já :-(






Tópicos Similares

  1. DNAT para SSH
    Por escambau no fórum Servidores de Rede
    Respostas: 4
    Último Post: 02-04-2003, 13:43
  2. Squid e DNAT
    Por lite no fórum Servidores de Rede
    Respostas: 1
    Último Post: 19-03-2003, 08:01
  3. Squid e DNAT
    Por no fórum Servidores de Rede
    Respostas: 1
    Último Post: 14-03-2003, 10:14
  4. SNAT E DNAT
    Por ediguedes no fórum Servidores de Rede
    Respostas: 2
    Último Post: 20-02-2003, 07:05
  5. NEWBIE IS ON THE WAY!
    Por Fabinho no fórum Servidores de Rede
    Respostas: 4
    Último Post: 05-12-2002, 23:41

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L