Encaminhamento de porta dinâmico baseado no nome do host ou ip de origem

6

Sou programador tentando descobrir algumas coisas além do meu domínio:

Digamos que eu tenha uma máquina e os clientes farão conexões tcp (mas não http!) com ela. Eu quero redirecionar os clientes para suas próprias portas com base em qual hostname eles se conectam. Por exemplo, o client1 se conecta ao client1.myserver.com e está conectado à porta 1234. client2.myserver.com - > 1235, client3.myserver.com - > 1236, etc.

Eu quero controlar dinamicamente como as portas x, para o host y realmente apontam para a porta z na minha máquina física.

Enquanto pesquisando essa informação, vejo referências a firewalls, proxies, proxies reversos. Qual software eu realmente preciso? O software existente permite essas alterações sob demanda (ouvi dizer que as alterações do firewall exigem um dia)?

Se eu quisesse escrever uma camada desse tipo (já que pode ser um pouco específico para uma aplicação), isso poderia ser feito em java ou node.js (quero dizer, isso poderia ser feito usando uma API de nível mais alto ou eu tenho que começar desmontando pacotes ip)? Como eu saberia qual hostname o cliente estava conectado, já que todos os nomes de host são resolvidos para a mesma máquina?

Também aprecio ponteiros para qualquer material de leitura.

    
por user23398 03.04.2011 / 07:00

3 respostas

9

No nível do IP, não existe um nome de host. Um nome de host é uma abstração em nível de aplicativo de um endereço IP e, nas camadas Internet ou Transporte, não tem significado.

Na hospedagem compartilhada HTTP, esse truque é abstraído no processo de manipulação da conversa HTTP , que acontece após a conversa TCP é iniciada. É por esse motivo que a execução de um servidor SSL exigiu um endereço IP dedicado por tanto tempo, pois a conversação SSL ocorre antes do HTTP (isso já foi corrigido em versões mais recentes do TLS, onde o HOSTNAME agora pode ser incluído como parte da negociação SSL ).

Para uma instância HTTP de hospedagem compartilhada, os protocolos são negociados aproximadamente nesta ordem:

TCP -> SSL -> HTTP

Cada protocolo não pode ser iniciado até que os anteriores sejam concluídos. Até recentemente, apenas a última etapa da cadeia estava ciente dos nomes de host, e por isso dependia do software servidor da Web lidar com uma associação de muitos para um dos nomes de host ao IP.

Para um encaminhamento de porta dinâmico, isso só é possível se o protocolo de aplicação estiver de alguma forma ciente dos nomes de host. Algum dispositivo (seja software ou hardware) manipula a conexão TCP inicial com clientes e as primeiras etapas do protocolo de aplicativo (seja lá o que for) e encaminha a conexão para seu destino final com base no que recebeu.

As etapas exatas necessárias variam de acordo com o próprio protocolo de aplicativo. Alguns, como HTTP, incluem um cabeçalho HOSTNAME indicando o nome do host com o qual o cliente espera estar conversando. Outros, como alguns protocolos da Microsoft, utilizam registros SRV baseados em DNS para determinar uma combinação precisa de IP e . Como parece que você pode estar projetando seu próprio protocolo de aplicação a partir dos bolts out, sugiro seguir o exemplo do HTTP e incluir um cabeçalho HOSTNAME nas etapas iniciais de negociação do protocolo.

    
por 03.04.2011 / 07:16
1

Você pode conseguir isso mais facilmente usando registros SRV no seu DNS:

link

    
por 03.04.2011 / 07:08
1

Você pode descrever em termos mais claros o que está tentando fazer e por quê? O "porquê" ajudará muito. Quais são os clientes? Qual é o protocolo?

Existem várias maneiras de fazer isso com base nos protocolos e fluxos de dados.

Considere pf, iptables ou ebtables injection, veja "ssh blacklist" para exemplos. Veja o LVS, o HAproxy e outros balanceadores de carga para redirecionamento geral.

Um truque antigo é um sistema de "despertar". Isso funciona muito bem para o SSH ou outros protocolos criptografados que o tornam mais intensivo para determinar o domínio de origem (decodificar o cabeçalho). Isso deixa apenas uma única porta em execução quando ninguém está conectado.

  • SSH em uma única porta aberta (sem suporte de terminal necessário)
  • logar no sistema como userX (de preferência usando chaves), isso executa um script que inicia outra instância do servidor na porta XXXXX e responde ao cliente com o novo número de porta
  • a mensagem "porta XXXXX está aberta" é transferida de volta para o cliente, a sessão inicial do ssh é encerrada
  • cliente ou aplicativo cliente, em seguida, reconecta usando a porta agora aberta XXXXX
  • quando o cliente desconecta a instância alternativa na porta XXXXX é fechada e / ou a porta XXXXX é fechada.

Portas específicas podem ser atribuídas com base em chaves / usuários, pesquisa inversa, passagem de mensagens, etc. Alguns apenas deixam as instâncias em execução e abrem / fecham usando a injeção de firewall pf / iptables. Outros estendem isso usando uma regra de firewall para acionar a inicialização do serviço e não ter nenhum SSH inicial (ou outro serviço) em execução até que uma porta especificada seja pingada com um tipo específico de pacote. Eu prefiro uma regra de firewall personalizada "recentemente combinada" para bloquear pacotes perdidos e parar / iniciar as instâncias do servidor para menos interação dinâmica com o firewall.

Essa ideia pode funcionar com qualquer protocolo e serviço que possa ser codificado ou com script.

Materiais de leitura para redes TCP / IP: Qualquer coisa escrita ou recomendada por W. Richard Stevens. link

Não desconte usando túneis SSH como um substituto temporário em desenvolvimento. Estes poderiam conseguir tudo que você precisa sem código. Qual é o seu app? A comunicação não deveria ser segura? Como você está indo para a lista negra de hackers kiddie script? Isso é mais que você terá que escrever e depurar. Você deve estar compartimentando seu código de qualquer maneira, então desenvolva todo o resto usando SSH como transporte, encaminhamento de porta, criptografia, registro de uso, lista negra, etc. Então, quando tudo estiver pronto, escreva seu próprio mecanismo de protocolo de rede para substituir o SSH. Não há necessidade de acesso de terminal para usuários no servidor SSH do gateway para usar túneis.

    
por 14.05.2011 / 03:07