Proxying TCP por hostname

Question

Tenho várias portas TCP de servidores de jogos na minha única máquina host. O objetivo é fazer com que os usuários consigam se conectar ao server1.domain.net e que eles sejam direcionados com base nesse subdomínio. Meu primeiro instinto escreveu o seguinte, mas depois percebi que o tráfego TCP não teria nenhum cabeçalho para ler. Usando o HAProxy 1.5.8. Eu tentei fazer a mesma coisa usando vários backends, use_backend e linhas ACL completas, mas obtive o mesmo resultado (compreensivelmente).

listen game-listener
  bind x.x.x.x:22222
  mode  tcp
  use-server  server1 if { hdr(host) -i server1.domain.net }
  use-server  server2 if { hdr(host) -i server2.domain.net }
  server server1 localhost:22201 check
  server server2 localhost:22202 check

Existe uma verificação como hdr (host) que eu posso usar para conexões TCP? Ou estou fazendo certo e o jogo não está jogando bem?

Obrigado!

    

Answer 1

Como uma alternativa ao proxy (onde depende do protocolo da aplicação se é possível fazer com base nos nomes dos hosts) você pode querer verificar se o software cliente é SRV ciente, caso em que você deve ser capaz de configurá-lo apenas no DNS.

Um registro SRV tem o seguinte formato:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

No seu exemplo específico, onde você mencionou várias instâncias do Minecraft, deve ser possível fazer isso com base nos registros SRV e os registros podem ser parecidos com isto:

_minecraft._tcp.foo.example.com. 86400 IN SRV 0 5 25565 server1.example.com.
_minecraft._tcp.bar.example.com. 86400 IN SRV 0 5 25566 server1.example.com.

    

Answer 2

Despachando conexões para diferentes backends dependendo do hostname ao qual o cliente conectado é impossível na camada TCP.

Você terá que usar endereços IP separados para cada nome de host ou implementar o proxy na camada de aplicativo com código específico do protocolo para detectar o nome do host.

Esse proxy é possível para certos protocolos, mas não para outros. De fácil a impossível, os protocolos que eu sei o suficiente são:

• O HTTP é fácil de suportar. Todos os clientes HTTP / 1.1 e a maioria dos clientes HTTP / 1.0 enviarão um cabeçalho de host antes de esperar qualquer resposta de resposta do servidor. É provável que os clientes sem o cabeçalho do host tenham desaparecido há muito tempo, já que muitos sites atualmente não funcionam sem ele.
• O HTTPS pode ser suportado por todos os clientes com suporte a SNI. O SNI foi padronizado muito mais recentemente do que o HTTP / 1.1, ainda existem alguns clientes sem suporte a SNI.
• O DNS é possível de suportar, mas é um pouco complicado. Na maioria dos casos, você apenas operaria seu servidor DNS autoritativo diretamente em um endereço IP público, em vez de fazer proxy.
• O SMTP é possível de suportar, mas também complicado. Um proxy para SMTP provavelmente acabaria parecendo mais um retransmissor SMTP do que como um proxy.
• O SSH é impossível de suportar. O conceito de nomes de host simplesmente não existe no protocolo. O cliente pode usar o DNS para resolver o endereço IP do servidor e pode associar as chaves do host armazenadas aos nomes de host, mas isso é totalmente um detalhe de implementação no lado do cliente. Isso não seria visível para o proxy, portanto, não pode ser usado para distribuir conexões. Além disso, nenhuma informação útil é enviada em texto puro, e mesmo as poucas informações que são enviadas em texto não criptografado no início do protocolo SSH são autenticadas mais tarde no protocolo, então se você errar qualquer parte, a comunicação será interrompida. O que torna isso ainda mais difícil de lidar é o fato de que o cliente não envia nem um byte de carga até que o servidor envie um banner de volta ao cliente. Então o proxy não teria literalmente nenhuma informação para trabalhar.

Não tenho conhecimento de nenhum outro protocolo com um nome de host, que poderia ser usado para tais fins. Então eu estou supondo que a maioria dos protocolos que não estão na lista acima são impossíveis de serem procurados pelo hostname.