Виртуальная машина Proxmox не может пинговать внешний мир, но может пинговать хост.

Вопрос или проблема

Я пытаюсь настроить мой Proxmox, но что-то не так, и я не могу понять, в чем именно проблема.

Я просмотрел почти все результаты поиска в Google и почти все посты на форуме, но все равно не могу понять, что я делаю не так.

У меня есть следующий файл /etc/network/interface на хосте:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp0s31f6
iface enp0s31f6 inet static
    address  188.40.120.186
    netmask  255.255.255.192
    gateway  188.40.120.129
    up route add -net 188.40.120.128 netmask 255.255.255.192 gw 188.40.120.129 dev enp0s31f6
# route 188.40.120.128/26 via 188.40.120.129

iface enp0s31f6 inet6 static
    address  2a01:4f8:221:2dc8::2
    netmask  64
    gateway  fe80::1

auto enp0s31f6.4000
iface enp0s31f6.4000 inet static
    address  192.168.100.1
    netmask  24
    mtu 1400

auto vmbr0
iface vmbr0 inet static
    address  178.63.206.24
    broadcast 178.63.206.31
    netmask  32
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    bridge_maxwait 0
    pre-up brctl addbr vmbr0
    up ip route add 178.63.206.25/32 dev vmbr0
    up ip route add 178.63.206.26/32 dev vmbr0
    up ip route add 178.63.206.27/32 dev vmbr0
    up ip route add 178.63.206.28/32 dev vmbr0
    up ip route add 178.63.206.29/32 dev vmbr0
    up ip route add 178.63.206.30/32 dev vmbr0
    up ip route add 178.63.206.31/32 dev vmbr0

#iface vmbr0 inet6 static
#    address  2a01:4f8:221:2dc8::2
#    netmask  64

auto vmbr1
iface vmbr1 inet static
    address  10.20.30.1
    netmask  255.255.255.0
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up iptables -t nat -A POSTROUTING -s '10.20.30.0/24' -o enp0s31f6 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING

И следующий конфигурационный файл на машине:

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address  178.63.206.25
    netmask  255.255.255.255
    gateway  188.40.120.186
    post-up ip route add 188.40.120.186 dev ens18
    post-up ip route add default via 188.40.120.186 dev ens18
    post-down ip route add default via 188.40.120.186 dev ens18
    post-down ip route add default via 188.40.120.186 dev ens18
# route 188.40.120.128/26 via 188.40.120.129

auto ens18.4000
iface ens18.4000 inet static
    address  192.168.100.3
    netmask  24
    mtu 1400


auto ens19
iface ens19 inet static
    address  10.20.30.3
    netmask 255.255.255
    gateway 10.20.30.1

Идея сети заключается в том, что:

IP от VSwitch (192.168.100.X) ДОЛЖЕН достигать ВМ через 192.168.100.3, или через 192.168.100.1 с переадресацией порта/прокси.

ВНЕШНИЙ доступ НЕ ДОЛЖЕН достигать ВМ через 178.63.206.25 (но я думаю, это следует решать на уровне брандмауэра, чтобы позволить “черный ход/административный доступ”).

ВМ ДОЛЖЕН достигать внешних сетей для обновления с 10.20.30.3, так как хост не учитывается как дополнительный IP.

ВМ ДОЛЖЕН достигать машин в сети 192.168.100.X и/или по их публичному IP.

ВМ ДОЛЖЕН достигать хоста как из 192.168.100.X, так и по его “публичному IP”.

Сейчас ситуация следующая:
ВМ МОЖЕТ ДОСТИЧЬ хоста через 10.20.30.1

ВМ МОЖЕТ ДОСТИЧЬ хоста через 178.63.206.24

ВМ НЕ МОЖЕТ ДОСТИЧЬ хоста через 188.40.120.186, хотя ip neigh утверждает, что он достижим

ВМ НЕ МОЖЕТ ДОСТИЧЬ внешних сетей (например, 8.8.8.8)

ВМ УТВЕРЖДАЕТ, ЧТО МОЖЕТ ДОСТИЧЬ 192.168.100.1, но это выглядит неправдой, так как если я отключаю часть ens18.4000, он всё равно “достигает чего-то”. ХОСТ НЕ МОЖЕТ ДОСТИЧЬ 192.168.100.3

ХОСТ МОЖЕТ ДОСТИЧЬ 178.63.206.25

ВНЕШНИЙ доступ МОЖЕТ ДОСТИЧЬ хоста через 178.63.206.24

ВНЕШНИЙ доступ МОЖЕТ ДОСТИЧЬ хоста через 188.40.120.186

ВНЕШНИЙ доступ НЕ МОЖЕТ ДОСТИЧЬ ВМ через 178.63.206.25

ДРУГАЯ МАШИНА 192.168.100.2 может достичь 192.168.100.1, но не 192.168.100.3

В панели управления провайдера (Hetzner) указывается, что я могу использовать это.

Gateway: 188.40.120.186
Netmask: 255.255.255.248
Broadcast: 178.63.206.31

Я пробовал изменить маску сети как для vmbr0, так и для ens19, но это всё равно не работает как должно.

Также, я пробовал включать/выключать поддержку VLAN на обеих мостах.

Я что-то упускаю?

Спасибо за помощь!

Я бы попробовал это на хосте:

echo 1 > /proc/sys/net/ipv4/ip_forward

Чтобы сделать это изменение постоянным, отредактируйте файл /etc/sysctl.conf и раскомментируйте строки:

net.ipv4.ip_forward=1
# ...
net.ipv6.conf.all.forwarding=1

Будьте осторожны, используя директиву post-up/etc/network/interfaces) для настройки /proc/sys/net/ipv4/ip_forward, так как это ненадежно: содержимое файла может вернуть значение 0 через некоторое время.

Ответ или решение

Чтобы ваш Proxmox Virtual Environment корректно работал и виртуальные машины (VM) могли обмениваться данными с внешними сетями, важно правильно настроить сетевые интерфейсы как на хосте, так и на самих машинах. В описанной вами конфигурации имеются несколько элементов, которые могут быть причиной проблем с подключением VM к внешним сетям. Давайте подробно разберём текущую конфигурацию и возможные улучшения.

### Теоретическая основа (Theory)

**Маршрутизация и сетевые мосты**: Основой для понимания проблемы является знание о том, как работают сетевые мосты и маршрутизация в Linux. В простом виде, мост (или bridge) позволяет нескольким интерфейсам обмениваться данными друг с другом и работать, как если бы они находились в одной местной сети. Ваша конфигурация использует `vmbr0` и `vmbr1`, что создаёт виртуальные сети на хосте.

### Примеры из вашего описания (Example)

#### Проблемы сетевой конфигурации:
1. **Виртуальная машина не может подключиться к внешним IP-адресам (например, 8.8.8.8)**:
– Это может быть связано с неправильно настроенной маршрутизацией или неправильно работой NAT (Network Address Translation).

2. **Хост не может подключиться к VM через внутренний IP `192.168.100.3`**:
– Возможные причины: неправильные настройки мостов или iptables, неправильно настроенные интерфейсы в сетях 192.168.100.X.

3. **Внешние адреса недоступны с VM**:
– Из конфигурации видно, что IP `188.40.120.186` используется как шлюз для VM, поэтому, если этот IP неправильно настроен или не работает, подключения к внешним сетям не будет.

### Применение на практике (Application)

#### Проверка Forwarding и NAT:
1. **Параметры ip_forward**: Прежде всего, важно убедиться, что хост настроен для маршрутизации трафика между своими сетевыми интерфейсами.
“`bash
echo 1 > /proc/sys/net/ipv4/ip_forward
“`
Чтобы сделать это изменение постоянным, добавьте строку в файл `/etc/sysctl.conf`:
“`
net.ipv4.ip_forward = 1
“`
2. **NAT через iptables**:
– Используйте iptables для настройки NAT, чтобы трафик от VMs направлялся правильно. Проверьте, применяются ли правила NAT для подсети `10.20.30.0/24`.
“`bash
iptables -t nat -A POSTROUTING -s 10.20.30.0/24 -o enp0s31f6 -j MASQUERADE
“`

#### Настройка мостов и маршрутов:
1. **Интерфейс обрыва**: Убедитесь, что мост vmbr1 правильно настроен и что все интерфейсы, добавляемые к мосту, правильно сконфигурированы. Например, убедитесь, что у vmbr1 нет подключённых физических портов, раз вы хотите использовать мост исключительно для управления traffic между виртуальными интерфейсами.

2. **Маршрутизация**:
– Проверьте маршруты на хосте, чтобы убедиться, что трафик направляется правильно:
“`bash
ip route
“`
– Проверьте, установлены ли маршруты к вашей VM через правильные IP-шлюзы, которые вы указали.

#### Администрирование и безопасность:
1. **Firewall и Правила iptables**: Отключите временно iptables на хосте и VM, чтобы исключить возможность того, что какой-либо firewall блокирует соединения. Это делается осторожно, только в целях тестирования, после чего настройки следует вернуть и наладить корректную работу firewall.
“`bash
# Flush all iptables rules
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
“`
2. **VLAN и MTU**: Если вы используете VLAN, убедитесь, что все соответствующие пользователей интерфейсы правильно поддерживают VLAN и что MTU одинаков на всех связанных интерфейсах, что поможет избежать фрагментации пакетов.

#### Проверка и диагностика:
1. **ping и traceroute**: Используйте команды `ping` и `traceroute` для диагностики цикла жизни пакетов внутри сети и их следующего этапа в интернет. Например, убедитесь, что от VM можно “пингануть” как шлюз, так и IP-адреса в интернете.
2. **iptables LOG**: Включите логирование для iptables, чтобы анализировать, какие пакеты блокируются.
“`bash
iptables -A INPUT -j LOG –log-prefix “IPTables-INPUT: ” –log-level 4
iptables -A OUTPUT -j LOG –log-prefix “IPTables-OUTPUT: ” –log-level 4
“`
3. **Перезапуск сетевых интерфейсов**: После применения изменений в конфигурации перезапустите сетевые службы или интерфейсы:
“`bash
systemctl restart networking
“`

Подводя итог, проблемы с сетевой конфигурацией могут быть решены через тщательную проверку всех описанных выше компонентов. Бесперебойная работа требует, чтобы forwarding, маршрутизация, настройки мостов и правила безопасности были применены и согласованы между собой. Используя рекомендации и инструменты диагностики из вашего описания, шаг за шагом проверяйте и тестируйте изменения, пока не достигнете требуемой функциональности.

Оцените материал
Добавить комментарий

Капча загружается...