Maneira mais simples de configurar vários subdomínios para separar VMs em execução em um único host

Question

Problema:

Estou planejando configurar várias máquinas virtuais centos, rhel ou ubuntu virtualizadas em um único servidor host centos (provavelmente usando o KVM). Cada guest VM está executando uma instância de um webapp + alguns outros serviços / protocolos, e cada guest VM precisa estar acessível fora do host, em qualquer porta aberta, como se cada uma delas fosse uma caixa DNSed separada.

Eu sou (aparentemente) fraco em redes tech / config, então estou simplesmente tentando encontrar as primeiras arestas desse problema, ie. as principais abordagens que eu preciso olhar para obter uma posição sobre isso. Configuração de rede "pseudocódigo" se você quiser. :)

Exemplo:

Digamos que eu possua o domínio foo.com.

Eu tenho uma máquina física do CentOS DNSed como guests.foo.com.

Nesta máquina host física, tenho três VMs em execução. Eu quero que as VMs convidadas sejam acessadas como 1.guests.foo.com, 2.guests.foo.com e 3.guests.foo.com. As VMs convidadas executam as distribuições centos, rhel e ubuntu.

Cada VM precisa responder a qualquer porta (aberta localmente), não apenas ao tráfego http, mas também às conexões ssh e às operações git: protocol.

Por onde começo, qual é a abordagem mais elegante? O que, aproximadamente, o anfitrião e os convidados precisam, minimamente, para que isso funcione bem?

Nota:

Eu atualizarei o texto da pergunta + comentários enquanto aprendo mais.

    

Answer 1

A única maneira de ter vários sistemas atendendo a mesma porta em um endereço IP é se o protocolo do aplicativo fornecer informações extras que ajudem o servidor a identificar para qual hostname a solicitação foi originalmente destinada. Sem isso, tudo o que o servidor pode deduzir na camada TCP / IP é o endereço IP e a porta de destino, o que seria o mesmo para todos os seus nomes DNS.

A maioria dos protocolos não suporta o que você deseja. O HTTP é uma exceção, porque o HTTP / 1.1 inclui o cabeçalho Host: que informa ao servidor qual nome do host o cliente estava procurando. Em HTTP, isso é chamado de hospedagem virtual baseada em nome . No entanto, o SSL quebra isso novamente e, portanto, há uma extensão ainda mais nova chamada Indicação de nome de servidor que traz esse suporte para o SSL como bem. É esperado que todos os sistemas forneçam um Host: nos dias de hoje, mas o SNI ainda não é totalmente suportado em todos os lugares.

O protocolo git não fornece um nome de host. No entanto, o novo transporte smart HTTP do git é uma ótima maneira de executar git sobre HTTP em vez disso, o que permitiria que você fizesse o que quisesse.

Independentemente do que você está usando HTTP para, a maneira real de configurar isso seria executar um servidor proxy no seu endereço IP primário que usa hospedagem virtual baseada em nome para direcionar as solicitações para o computador correto.

Para o SSH, não há muitas opções além de usar portas diferentes. Você poderia criar seu próprio "host de rejeição" que funciona como o servidor proxy, exceto manualmente: os usuários primeiro se conectam ao seu endereço IP primário e fornece um mini shell que lhes permite mais ssh para os outros hosts (usando Endereços IP da LAN). Você terá dificuldades em fazer isso funcionar perfeitamente com protocolos não interativos, como o SFTP ou outras conexões automatizadas. A outra abordagem pode ser criar um servidor SSH que use informações no nome de usuário para decidir a qual host se conectar automaticamente: por exemplo, o comando ssh [email protected] pôde se conectar ao seu endereço IP único e, em seguida, um servidor SSH modificado lá extrai o nome de usuário e faz uma nova conexão com username@machine1 . Não conheço nenhum software existente que possa ajudá-lo a fazer isso; provavelmente seria necessário ser escrito.

É claro que, se você usar o IPv6, poderá fornecer a cada máquina um milhão de endereços públicos e não precisará de nenhum desses truques.