SSHing к моему серверу XCP-ng подключается к гипервизору, а не к виртуальной машине, даже при использовании отдельных IP-адресов

Question

У меня есть старый сервер HP ProLiant DL385 G5p, который я использовал для использования только в качестве прославленного NAS, но теперь я хотел бы сделать с ним что-то большее, например, настроить кеширующий DNS-сервер для моей сети.

Я хотел бы иметь возможность запускать мой файловый сервер и DNS (и все остальное, о чем я могу думать) на отдельных виртуальных машинах через гипервизор XCP-ng.

Я начал настраивать это за последние пару дней, запустил две мои виртуальные машины Debian и даже смог заставить работать мой кеширующий DNS. Однако моя проблема возникла, когда я попытался подключиться через SSH к виртуальной машине Debian, которую я хотел использовать для своего файлового сервера. Я поместил IP-адрес этой виртуальной машины в PuTTY (у меня было два Ethernet-подключения к серверу: одно для файлового сервера и одно для всего остального), и он подключился нормально - к гипервизору. Это проблема, и я действительно не уверен, что здесь происходит. Как мне сделать PuTTY и, следовательно, SFTP-диск, который я буду использовать для передачи файлов на мой основной ПК, подключаться к виртуальной машине вместо гипервизора.

Один из моих друзей упомянул, что мне, возможно, придется использовать переадресацию портов на гипервизоре, чтобы иметь возможность подключаться к ним по SSH, и я изучил это, но не нашел ничего, что могло бы помочь, хотя я не уверен на 100%, что Я ищу.

С тех пор я переустанавливал XCP-ng и настраивал кеширующий DNS и узел ретрансляции tor на одном соединении Ethernet, но мне все еще нужно создать другую установку Debian для файлового сервера.

Заранее спасибо.

Изменить: это вывод, который я получаю, когда я запускаю route на гипервизоре:

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

И это вывод ВМ:

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

Надеюсь, что это может быть полезным.

Редактировать (1): это результат выполнения route -n на гипервизоре:

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

Мы должны понимать модель сети, которую вы используете в гипервизоре.

Если виртуальные машины работают в той же IP-сети, что и гипервизор, т. Е. Гипервизор не выполняет маршрутизацию IP-сети, переадресация портов не требуется.

Однако это не самая распространенная ситуация. Обычно, когда вы настраиваете виртуальные машины, вы держите их в отдельной сети и используете некоторую переадресацию портов на гипервизоре, чтобы немного повысить безопасность, сводя к минимуму количество открытых машин.

Поэтому, скорее всего, вам нужно настроить правило переадресации портов в iptables чтобы сопоставить, скажем, порт 2022 в IP-адресе гипервизора с портом 22 виртуальной машины.

В следующем примере предположим, что ваш гипервизор настроил подсеть 192.168.1.0 с маской сети 255.255.255.0 (24 бита, класс C). Также предположим, что ваша виртуальная машина имеет адрес 192.168.1.2. Затем, если у вас есть правильно настроенный межсетевой экран на гипервизоре, который по умолчанию запрещает все соединения, следующие две строки должны выполнить задачу:

$ 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

Рекомендации:

[1] https://www.systutorials.com/816/port-forwarding-using-iptables/

Answer 2

Итак, после того, как Марсело довольно много покопался и помог мне ответить на мой вопрос, я выяснил, в чем проблема, почему я не могу подключиться к своей ВМ.

Спойлер: это смущающе просто.

Короче говоря, я нашел способ проверить IP-адрес, который был назначен порту Ethernet, который я пытался использовать, с помощью ip a show eth1 , который было бы удобно знать, чтобы существовать.

Оказывается, по какой-то причине - возможно, из-за того, что гипервизор делал что-то сложное - даже когда я установил IP для использования в /etc/network/interfaces как статический, он решил присвоить ему другой. После того, как я узнал IP-адрес, который он использовал, я смог подключиться к виртуальной машине без проблем.