O SSHing para o meu servidor XCP-ng conecta-se ao hipervisor e não à VM, mesmo quando se usa IPs separados

Question

Eu tenho um antigo servidor HP ProLiant DL385 G5p que costumava usar apenas como um NAS glorificado, mas agora gostaria de fazer algo mais com ele, como configurar um servidor DNS de cache para minha rede.

Eu gostaria de poder executar o meu servidor de arquivos e o DNS (e qualquer outra coisa que eu possa pensar) em máquinas virtuais separadas através do hipervisor XCP-ng.

Eu comecei a configurar isso nos últimos dois dias, consegui instalar duas das minhas VMs Debian e até consegui colocar meu DNS em cache funcionando. No entanto, o meu problema veio quando tentei conectar via SSH à máquina virtual Debian que eu queria usar para o meu servidor de arquivos. Eu coloquei o IP dessa VM no PuTTY (eu tinha duas conexões Ethernet para o servidor; uma para o servidor de arquivos e outra para todo o resto), e ela se conectava bem - ao hipervisor. Este é o problema e eu realmente não tenho certeza do que está acontecendo aqui. Como eu faço PuTTY, e, portanto, SFTP Drive, que eu vou estar usando para transferências de arquivos para o meu PC principal, conecte-se à VM em vez do hipervisor.

Um dos meus amigos mencionou que talvez eu precise usar o encaminhamento de porta no hipervisor para poder fazer o SSH neles e examinei isso, mas não encontrei nada que parecesse que ajudaria, embora eu não seja 100 % sure o que estou procurando.

Eu já reinstalei o XCP-ng e configurei o DNS de cache e um nó de relé tor em uma conexão ethernet, mas ainda preciso criar outra instalação do Debian para o servidor de arquivos.

Obrigado antecipadamente.

Edit: Esta é a saída que recebo quando executo route no hypervisor:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default gateway 0.0.0.0 UG 0 0 0 xenbr0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr0

E esta é a saída da VM:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Espero que isso possa ser útil.

Edit (1): Esta é a saída da execução de route -n no hypervisor:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 xenbr0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr0

    

Answer 1

Ok, então depois de muita investigação e da ajuda de Marcelo que tentou responder à minha pergunta, descobri qual era o problema de não conseguir me conectar à minha VM.

Spoiler: é embaraçosamente simples.

Para encurtar a história, encontrei uma maneira de verificar o endereço IP que foi atribuído à porta ethernet que eu estava tentando usar usando ip a show eth1 , o que teria sido útil saber que existia.

Acontece que, por algum motivo - provavelmente devido ao hypervisor fazer algo complicado - mesmo quando eu configurei o IP para usar em /etc/network/interfaces como estático, ele estava decidindo dar um diferente . Uma vez que eu soube o IP que estava usando, eu poderia SSH na VM sem problemas em tudo.

    

Answer 2

Precisamos entender o modelo de rede que você está usando no hipervisor.

Se as VMs forem executadas na mesma rede IP que o hipervisor, ou seja, o hypervisor não executa roteamento de rede IP, não deve haver necessidade de encaminhamento de porta.

No entanto, esta não é a situação mais comum. Normalmente, quando você configura as VMs você mantê-los em uma rede separada e usar algum tipo de encaminhamento de porta em hipervisor para melhorar um pouco a segurança, minimizando o número de máquinas expostas.

Então, provavelmente você precisa configurar uma regra de encaminhamento de porta em iptables para mapear digamos a porta 2022 no IP do hipervisor para a porta 22 da VM.

No exemplo a seguir, suponha que seu hipervisor configura uma sub-rede 192.168.1.0 com máscara de rede 255.255.255.0 (24 bits, classe C). Além disso, suponha que sua VM tem o endereço 192.168.1.2. Então, se você tiver um configurado corretamente firewall no hipervisor que nega todas as conexões por padrão, o seguir duas linhas deve executar a tarefa:

$ iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 2022 -j DNAT --to 192.168.1.2:22
$ iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 22 -j ACCEPT

Referências:

[1] link