Rota de tráfego SSH com base no domínio com HAProxy

Question

Atualmente, estou construindo meu próprio cluster pequeno em casa e estou tentando obter o roteamento de SSH (balanceamento de carga) para trabalhar com o HAProxy. Eu descobri como rotear o tráfego HTTP, mas estou lutando com o SSH. Eu não sei o suficiente sobre o protocolo TCP para saber instantaneamente o que eu tenho que procurar para que eu possa determinar como consultar conexões para algo como um host (não tenho certeza se isso é mesmo em algum lugar na conexão) ou apenas qualquer coisa que possa identificar em qual servidor eu quero o SSH.

A documentação menciona o tráfego SSH repetidas vezes, então pode haver algo que eu perdi. Eu não quero usar portas diferentes e ir e voltar usando portas diferentes porque elas podem não ser padrão, portanto, são bloqueadas em redes públicas ou outras coisas que me restringiriam.

Minha configuração atual é assim:

Solicitação nos meus domínios (ou IP) - > Roteador - > NAT para frente, dependendo da porta - > HAProxy escutando naquela porta - > Agora, deve identificar o tráfego dedicado a um determinado servidor e tráfego de proxy em relação a ele.

Editar: Como o Cha0s esclareceu isso simplesmente não é possível com o SSH (ou similar).

Se você estiver interessado em um método diferente, a resposta de Sven dará uma boa visão sobre como fazer algo semelhante, mas ter subdomínios diferentes resolverá para IPs estáticos públicos diferentes

    

Answer 1

Eu acredito que você está misturando termos.

O balanceamento de carga normalmente significa que você se conecta a um host ( example.com ) e permite que o balanceador de carga distribua todas as conexões para um ou mais hosts de backend, geralmente sem controle do usuário com qual host você está se conectando. Isso pode ser feito facilmente para o SSH de várias maneiras.

Alguns protocolos, como o HTTP com o cabeçalho Host , podem fornecer ao balanceador de carga mais informações para decidir para quais servidores de backend a conexão deve ser roteada (por exemplo, example.com é roteado para a e b , enquanto example.org é roteado para c e d ).

O SSH não tem esse campo e, portanto, isso não pode ser feito com um balanceador de carga e apenas com um endereço IP. Isso torna uma LB inadequada para essa tarefa.

Normalmente, isso é resolvido usando um host como um host / gateway / jumper de SSH e instrui seus clientes SSH a usá-lo como tal. Se você usa o OpenSSH, coloque o seguinte em seus clientes ~/.ssh/config

Host  *.internal.lan
   ProxyCommand ssh -q -A  -x proxy.example.com -W %h:%p

Agora, se você se conectar aos nomes listados na linha Host , seu cliente SSH primeiro se conectará a proxy.example.com (que deve apontar para seu endereço IP público) e o usará como um gateway para encaminhar para o máquina (use o encaminhamento de porta NAT para a porta 22 de sua máquina proxy atual, se aplicável). Observe que proxy.example.com deve poder resolver *.internal.lan . Configure um servidor DNS ou use o servidor interno oferecido pelo seu roteador para conseguir isso.

Depois disso, de uma rede externa, você se conecta ao nas.internal.lan para acessar seu NAS (ou raspi.internal.lan etc ...) e, de dentro da sua rede local, você usa apenas nas ou raspi a conexão é direta e não via gateway).

Outra maneira, dado o fato de você usar o NAT:

Crie encaminhamentos de porta em seu roteador NAT, por exemplo como

Port 2210 -> internal host1, port 22
Port 2211 -> internal host2, port 22

e, em seguida, coloque o seguinte em seus clientes ~/.ssh/config :

Host host1.example.com  
   Port 2210

Host host2.example.com 
   Port 2211

e verifique se host1/2.example.com apontam para seu endereço IP externo.

Em seguida, você pode simplesmente se conectar via SSH a host1.example.com e o OpenSSH se conectará à porta 2210, que é encaminhada para seu host1 interal pelo gateway NAT.

Ambos os métodos funcionam no seu cenário.

    

Answer 2

AFAIK você não pode fazer isso com base no domínio. O HTTP pode funcionar assim porque possui um cabeçalho especial Host , que os navegadores (um proxies inversos neste caso) podem entender e tomar decisões com base nele.

Em outros protocolos TCP, não tenho conhecimento de nada semelhante. Definitivamente não no SSH.