Encaminhamento de porta via xinetd em ambiente NATed

Question

Estou trabalhando em uma configuração que requer redirecionamento de solicitação em uma das portas do servidor para a porta de outro servidor em um ambiente NATed (exemplo: todas as solicitações que chegam em 192.168.1.100:843 devem ser redirecionadas para 192.168.1.200:8443 - ambos os servidores estão atrás de um firewall dedicado e se comunicam entre si em todas as portas.)

Um serviço está sendo executado na porta 8443 do servidor 192.168.1.200. Eu configurei o encaminhamento de porta no servidor 192.168.1.100 via xinetd da seguinte forma.

service serv1
{
        bind            = 192.168.1.100
        protocol        = tcp
        flags           = REUSE
        socket_type     = stream
        port            = 843
        wait            = no
        user            = root
        redirect        = 192.168.1.200 8443
}

Agora, quando estou fazendo o telnet para 192.168.1.100 843 na LAN, posso conectar o serviço em 192.168.1.200:8443

-> telnet 192.168.1.100 843
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.

Mas quando estou tentando conectar via IP público do 192.168.1.100 estou recebendo "conexão fechada"

-> telnet 1.2.3.4 843
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
Connection closed by foreign host.

Ao fazer o tcpdump eu encontrei no último caso o pedido não está vindo para o servidor 192.168.1.200 em si.

Estou tendo uma configuração semelhante trabalhando em um de nossos DC & está funcionando bem. Qualquer ideia de que algo poderia dar errado aqui.

Obrigado Meghanand

    

Answer 1

Bem, após uma investigação mais aprofundada, descobri que estava sendo bloqueado devido ao TCPWrappers Depois de adicionar regras apropriadas, ele funciona bem.

A seguir, adicionado ao /etc/hosts.allow

serv1: ALL

Obrigado

    

Answer 2

Você precisa remover a linha bind , se quiser que ela esteja escutando em todos os IPs atribuídos ao host.

Isso, no entanto, não pode ser uma explicação completa para o seu problema. Se esse foi o único erro cometido, as conexões com o outro IP teriam a conexão recusada, e não uma conexão estabelecida seguida por uma desconexão.

Outra coisa pode estar escutando no mesmo número de porta no outro endereço IP. Isso pode até ser um serviço xinetd diferente. Se você tiver outro xinetd service, que é semelhante a isso, isso poderia explicar o problema:

service serv2
{
        bind            = 192.0.2.42
        protocol        = tcp
        flags           = REUSE
        socket_type     = stream
        port            = 843
        wait            = no
        user            = root
        redirect        = 192.168.1.200 61868
}

Aqui, as diferenças são que o outro está escutando em um IP diferente (mas o mesmo número de porta) e se conectando a outro número de porta, que é fechado. Se foi isso que você fez, as conexões com o outro endereço IP obterão uma conexão estabelecida, que xinetd precisa fechar quando perceber que a porta de destino do redirect está fechada.

A última parte é apenas adivinhando. Se você executar netstat -ntlpW , poderá ver o que realmente está escutando nesse outro IP.