1

Недавно я настроил Proxmox в качестве хоста виртуализации. Это просто KVM + Debian в хорошем дистрибутиве Linux. Моя домашняя сеть 192.168.12.0/24. Я хотел использовать 192.168.14.0/24 в качестве подсети для всех моих виртуальных машин на машине Proxmox. Я использую DHCP для настройки почти всех моих хостов. Если я хочу использовать static-ip, я обычно просто настраиваю резервирование DHCP для устройства вручную. Итак, я хотел, чтобы мои виртуальные машины получали адреса DHCP в подсети 192.168.14.0/24.

Когда я установил Proxmox, он создал мост с именем vmbr0 который соединен с eth0 . IP-адрес моста 192.168.12.12 .

Я добавил мост в /etc/network/interfaces под названием vmbr14 соединенный с eth0.14 . Я дал ему IP 192.168.14.12 . Я также установил modprobe'd в модуле 8021q и добавил его в /etc/modules .

Мой DHCP-сервер живет на другой машине 192.168.12.95 с интерфейсом eth0 на нем. Я добавил другой интерфейс с именем eth0.14 и присвоил ему IP 192.168.14.95 . Я обновил /etc/dhcp/dhcpd.conf другим пулом для подсети 192.168.14.0 . Указанный маршрут по умолчанию - 192.168.14.12 , машина Proxmox. DHCP работал сразу без проблем.

Чтобы хосты в сети 192.168.12.0/24 узнали, как маршрутизировать 192.168.14.0/24 я пошел в свой интернет-шлюз (192.168.12.2) и добавил маршрут следующим образом.

192.168.14.0    192.168.12.12   255.255.255.0   UG    1      0        0 eth2

В окне Proxmox уже включена пересылка для IPv4.

ericu@basov:~$ cat /proc/sys/net/ipv4/ip_forward 
1

После этого все заработало. Я могу SSH и пинговать свои виртуальные машины со своего рабочего стола без проблем.

Но на самих виртуальных машинах я не могу достичь 192.168.12.95 только 192.168.14.95 . Я сделал ping на одной из виртуальных машин до 192.168.12.95 и перехватил пакет, используя tcpdump

ericu@katz:~$ sudo tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:50:16.007898 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 18, length 64
18:50:17.010380 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 19, length 64
18:50:18.012969 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 20, length 64
18:50:19.015433 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 21, length 64
18:50:20.018043 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 22, length 64

Пакеты, очевидно, попадают в машину, но я понятия не имею, что происходит после этого. Машина просто не отвечает. TCP также не работает.

ericu@katz:~$ sudo tcpdump -n tcp port 3000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:53:21.048128 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 665263 ecr 0,nop,wscale 7], length 0
18:53:22.051442 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 666264 ecr 0,nop,wscale 7], length 0
18:53:24.060540 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 668268 ecr 0,nop,wscale 7], length 0

Если я пытаюсь получить доступ к IP 192.168.14.95 с виртуальных машин, все работает нормально.

Если я это сделаю, тогда на ifdown eth0.14 на машине 192.168.12.95 . Очевидно, что это не практично, так как сервер DHCP должен быть доступным.

Почему машины в подсети 192.168.14.0/24 достигать машины только по адресу 192.168.14.95 а не по адресу 192.168.12.95 ?

Таблица маршрутизации на 192.168.12.95

ericu@katz:~$ ip route show
default via 192.168.12.2 dev eth0  metric 100 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.95 
192.168.14.0/24 dev eth0.14  proto kernel  scope link  src 192.168.14.95 
ericu@katz:~$ 

Это таблица маршрутизации на 192.168.14.130

[ericu@squid3 ~]$ ip route show
default via 192.168.14.12 dev ens18  proto static  metric 1024 
192.168.14.0/24 dev ens18  proto kernel  scope link  src 192.168.14.130 
[ericu@squid3 ~]$ 

Чтобы устранить эту проблему, я создал виртуальную машину на своем рабочем столе. Я отредактировал /etc/network/interfaces следующим образом

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp


auto eth0.14
iface eth0.14 inet static
    address 192.168.14.14
    netmask 255.255.255.0

Машина получила адрес DHCP на eth0 192.168.12.172 . С 192.168.12.130 я все еще не мог получить к нему доступ, используя 192.168.12.172 . На тестовой ВМ я изменил /etc/iproute2/rt_tables чтобы он выглядел следующим образом

#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
14 vlan14

Затем я выполнил следующие команды

root@ubuntuvmdesktop:/home/ericu# ip route show
default via 192.168.12.2 dev eth0 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.172 
192.168.14.0/24 dev eth0.14  proto kernel  scope link  src 192.168.14.14 
root@ubuntuvmdesktop:/home/ericu# ip route del 192.168.14.0/24 dev eth0.14 src 192.168.14.14
root@ubuntuvmdesktop:/home/ericu# ip route show
default via 192.168.12.2 dev eth0 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.172 
root@ubuntuvmdesktop:/home/ericu# ip route add 192.168.14.0/24 dev eth0.14 src 192.168.14.14 table vlan14
root@ubuntuvmdesktop:/home/ericu# ip route add default via 192.168.14.12 dev eth0.14 src 192.168.14.14 table  vlan14
RTNETLINK answers: Network is unreachable
root@ubuntuvmdesktop:/home/ericu# ip rule add from 192.168.14.14 table vlan14
root@ubuntuvmdesktop:/home/ericu# ip route show table vlan14
192.168.14.0/24 dev eth0.14  scope link  src 192.168.14.14 

После этого виртуальная машина с IP-адресом может связаться с машиной, используя 192.168.14.14 и 192.168.12.172

[ericu@squid3 ~]$ nc -v 192.168.12.172 22
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.12.172:22.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
^C
[ericu@squid3 ~]$ nc -v 192.168.14.14 22
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.14.14:22.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
^C
[ericu@squid3 ~]$ 

Так что это как минимум один из способов решения проблемы. Однако я не очень понимаю, что он делает. Я понимаю, что я добавил отдельную таблицу маршрутизации под названием «vlan14» к машине. Я предполагаю, что с помощью ip rule add каким-то образом направляет трафик, предназначенный для 192.168.14.14 в свою собственную таблицу маршрутизации. Изолирует ли это маршрутизацию для двух подсетей в их собственную таблицу маршрутизации? Однако все изменения маршрута, которые я сделал с использованием ip route , не сохраняются при перезапуске. Кажется, мне нужно обновить /etc/network/interfaces чтобы как-то указать, что маршруты должны идти в эту альтернативную таблицу маршрутизации.

Может кто-нибудь объяснить, как работает отдельная таблица маршрутизации? Может кто-нибудь объяснить, как изменить мою конфигурацию, чтобы изменения, сделанные с помощью команды ip , сохранялись при перезагрузке?

1 ответ1

1

Вся linux маршрутизация осуществляется через таблицы маршрутизации.

Установка по умолчанию без каких-либо изменений будет иметь "основную" таблицу, таблицу "по умолчанию" и "локальную" таблицу. Таблица "main" отображается, если вы запускаете ip route show без дополнительных опций; "Локальная" таблица предназначена для петлевых адресов (127.0.0.0/8 , ff00::/8). Таблица "по умолчанию" используется в качестве крайней меры и обычно пуста.

Вы можете добавить специальные инструкции по маршрутизации, которые применяются к адресатам, выбранным командой ip rule . Вы добавляете правила с приоритетом, младшие номера сопоставляются первыми. По умолчанию это правила по умолчанию:

$ ip rule show
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

Типичное использование правил - это если у вас многосетевая система, то есть система с несколькими подключениями к Интернету. В этой настройке вы должны убедиться, что ответные пакеты отправляются через тот же интерфейс (т. Е. Интернет-соединение), что и исходный пакет. Обычно это означает, что пакеты с определенным адресом источника отправляются с соответствующего интерфейса:

# ip rule add from 1.2.3.4 pref 30000 lookup first
# ip rule add from 5.6.7.8 pref 30000 lookup second
# ip route add table first  default via 1.2.3.254 dev if1 src 1.2.3.4
# ip route add table second default via 5.6.7.254 dev if2 src 5.6.7.8

Теперь добавьте маршрут по умолчанию, который проходит через предпочтительное соединение (например, самый быстрый или самый дешевый по объему):

# ip route add table default via 5.6.7.254 dev if2 src 5.6.7.8

Добавьте второй маршрут по умолчанию, когда предпочтительный интерфейс отключается:

# ip route add table default via 1.2.3.254 dev if1 src 1.2.3.4

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

Вы можете использовать разные селекторы в ip rule add , например, сделать так, чтобы он зависел от метки брандмауэра, установленной в пакете iptables . Используйте ip rule add help для того, что вы можете поместить туда; это относится в целом ко всем командам ip (например, ip help , ip route help).

Linux Advanced Routing Guide описывает все об этом предмете.


Чтобы сделать ручную настройка маршрута применяется после перезагрузки и т.д., добавьте их в /etc/network/interfaces и т.д. / сеть / интерфейсы определение интерфейса с post-up добавлены перед, тем будет выполняться после того, как интерфейс приходит. man interfaces описывает все возможные вещи, которые вы можете поместить в файл interfaces .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .