несколько устройств macvlan и путаница в маршрутизации на основе политик

У меня есть сервер (ubuntu / debian) с двумя подключениями к интернет-провайдеру. Оба этих WAN-соединения имеют несколько общедоступных IP-адресов.

(big pipe)----eth0-->\
                      > server ---eth2--(internal)
(cable pipe)--eth1-->/

На eth0 мне назначено 4 IP-адреса, которые являются частью более широкой подсети / 24. 24.xxx.xxx.xxx/24 На eth1 мне назначено 5 IP-адресов, но здесь я единственный на a / 29 (шестой IP-адрес - это шлюз, который я выбрал) 71.xxx.xxx.xxx/29

Моя цель - настроить маршрутизацию на основе источника / политики, чтобы виртуальные машины / клиенты в различных внутренних подсетях (на eth2 есть несколько фактических VLANS) могли маршрутизироваться в Интернет по любому указанному IP-адресу WAN.

Вот что я сделал до сих пор.

Сначала я настроил eth0 и eth1 в файле интерфейсов.

auto eth0
iface eth0 inet static
        address 24.xxx.xxx.66
        netmask 255.255.255.0
        network 24.xxx.xxx.0
        broadcast 24.xxx.xxx.255
        gateway 24.xxx.xxx.1
        dns-nameservers 8.8.8.8
        up /etc/network/rt_scripts/i_eth0

auto eth1
iface eth1 inet static
        address 71.xxx.xxx.107
        netmask 255.255.255.248
        network 71.xxx.xxx.105
        broadcast 71.xxx.xxx.111
        up /etc/network/rt_scripts/i_eth1

Затем устройства macvlan на BigPipe

#!/bin/sh

#iface BigPipe67
ip link add mac0 link eth0 address xx:xx:xx:xx:xx:3c type macvlan
ip link set mac0 up
ip address add 24.xxx.xxx.67/24 dev mac0

#iface BigPipe135
ip link add mac1 link eth0 address xx:xx:xx:xx:xx:3d type macvlan
ip link set mac1 up
ip address add 24.xxx.xxx.135/24 dev mac1

#iface BigPipe136
ip link add mac2 link eth0 address xx:xx:xx:xx:xx:3e type macvlan
ip link set mac2 up
ip address add 24.xxx.xxx.136/24 dev mac2

/etc/network/rt_scripts/t_frontdesk
/etc/network/rt_scripts/t_pubwifi
/etc/network/rt_scripts/t_mail1
/etc/network/rt_scripts/t_scansrvc

Связь CBL. Отсутствующий 5-й IP-адрес (71.xxx.xxx.106) - это другой маршрутизатор, расположенный в здании.

#!/bin/sh
ip route add xxx.xxx.xxx.xxx/20 via 71.xxx.xxx.105 dev eth1
ip route add xxx.xxx.xxx.xxx/20 via 71.xxx.xxx.105 dev eth1

#iface CBL108
ip link add mac3 link eth1 address xx:xx:xx:xx:xx:c5 type macvlan
ip link set mac3 up
ip address add 71.xxx.xxx.108/29 dev mac3

#iface CBL109
ip link add mac4 link eth1 address xx:xx:xx:xx:xx:c6 type macvlan
ip link set mac4 up
ip address add 71.xxx.xxx.109/29 dev mac4

#iface CBL110
ip link add mac5 link eth1 address xx:xx:xx:xx:xx:c7 type macvlan
ip link set mac5 up
ip address add 71.xxx.xxx.110/29 dev mac5

/etc/network/rt_scripts/t_jenkins4
/etc/network/rt_scripts/t_skynet
/etc/network/rt_scripts/t_lappy386

Вы заметите, что у меня есть пара маршрутов, указанных в основной таблице, когда я настраиваю интерфейсы macvlan на eth1. У меня есть пара других маршрутизаторов на том же кабельном провайдере, что и мой основной сервер. Они возвращаются к основному серверу через VPN, а BigPipe используется для всего остального (в основном столе).

Сценарии «t_» используются для настройки отдельных правил и таблиц для различных служб / клиентов, которые использовали IP-адреса, настроенные интерфейсами macvlan.

В упрощенном виде они выглядят примерно так.

#!/bin/sh
ip rule add from 172.23.1.6 table scansrvc
ip route add default via 24.xxx.xxx.1 dev mac0 table scansrvc
ip route add 24.xxx.xxx.0/24 dev mac0 table scansrvc
ip route add 172.23.0.0/20 dev br1 table scansrvc

Итак, если собрать все это вместе и вкратце подвести итог, у меня есть главный сервер, использующий 8 общедоступных IP-адресов (4 на BigPipe и 4 на CBL). Один из IP-адресов BigPipe и один из IP-адресов CBL используются для служб VPN, эффективно создавая "интернет-обмен в гетто", если хотите. Эта конфигурация маршрутизации существует в основной таблице.

Затем оставшиеся 6 IP-адресов используются различными службами или клиентами, и этими таблицами являются frontdesk, pubwifi, mail1, scansrvc, jenkins4, skynet и lappy386.

Я маскирую все общедоступные IP-адреса в различные внутренние подсети.

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

Итак, на scansrvc, который представляет собой виртуальную машину на главном сервере, но с внутренним IP-адресом (172.23.1.6/20)

waffle@scansrvc:~$ dig +short myip.opendns.com @resolver1.opendns.com
24.xxx.xxx.67

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

Когда он работает, и я просматриваю извне, я вижу служебный порт, но после его смерти iptables даже не видит, что пакеты попадают внутрь.

Кроме того, в процессе поиска я начал читать о марсианских пакетах. Поэтому я включил их регистрацию через sysctl. Вот это да. Я регистрирую тонну марсиан из BigPipe, но ни одного из CBL, возможно, потому, что BigPipe я не единственный в этой подсети?

Вот отрывок

Nov 22 08:59:03 srv3 kernel: [  271.747016] net_ratelimit: 497 callbacks suppressed
Nov 22 08:59:03 srv3 kernel: [  271.747027] IPv4: martian source 24.xxx.xxx.43 from 24.xxx.xxx.1, on dev mac0
Nov 22 08:59:03 srv3 kernel: [  271.747035] ll header: 00000000: ff ff ff ff ff ff cc 4e 24 9c 1d 00 08 06        .......N$.....
Nov 22 08:59:03 srv3 kernel: [  271.747046] IPv4: martian source 24.xxx.xxx.43 from 24.xxx.xxx.1, on dev mac2
Nov 22 08:59:03 srv3 kernel: [  271.747052] ll header: 00000000: ff ff ff ff ff ff cc 4e 24 9c 1d 00 08 06        .......N$.....
Nov 22 08:59:03 srv3 kernel: [  271.747061] IPv4: martian source 24.xxx.xxx.43 from 24.xxx.xxx.1, on dev mac1
Nov 22 08:59:03 srv3 kernel: [  271.747066] ll header: 00000000: ff ff ff ff ff ff cc 4e 24 9c 1d 00 08 06        .......N$.....
Nov 22 08:59:03 srv3 kernel: [  271.796429] IPv4: martian source 24.xxx.xxx.211 from 24.xxx.xxx.1, on dev mac0
Nov 22 08:59:03 srv3 kernel: [  271.796440] ll header: 00000000: ff ff ff ff ff ff cc 4e 24 9c 1d 00 08 06        .......N$.....
Nov 22 08:59:03 srv3 kernel: [  271.796450] IPv4: martian source 24.xxx.xxx.211 from 24.xxx.xxx.1, on dev mac2

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

Что могло бы вызвать это? Почему, когда я только что загружаю систему и VMS, установка будет работать до тех пор, пока через некоторое время внезапно не умрет? (Например, если я оставлю команду ping на 8.8.8.8 на виртуальной машине scansrvc, я получу 100-1000 ответов, прежде чем она умрет) Может это быть что-то с кешем ARP? Это не похоже на то, что я переназначаю какие-либо IP-адреса на разные MAC-адреса во время полета.

Я застрял. Я собираюсь начать изучать некоторые навыки работы с tcpdump, чтобы попытаться пролить свет на то, что мне, возможно, не хватает. Если бы кто-нибудь, кто лучше разбирается в сетевых настройках, мог указать на то, что мне не хватает, это было бы огромной помощью! :)