Два сетевых интерфейса и два IP-адреса в одной подсети в Linux

Недавно я столкнулся с ситуацией, когда мне потребовалось два IP-адреса в одной подсети, назначенных одному хосту Linux, чтобы мы могли запустить два сайта SSL / TLS. Мой первый подход состоял в том, чтобы использовать псевдонимы IP, например, используя eth0: 0, eth0: 1 и т. Д., Но у наших сетевых администраторов есть довольно строгие настройки для безопасности, которые подорвали эту идею:

1. Они используют отслеживание DHCP и обычно не допускают статические IP-адреса. Статическая адресация выполняется с использованием статических записей DHCP, поэтому один и тот же MAC-адрес всегда получает одно и то же назначение IP. Эта функция может быть отключена для каждого порта коммутатора, если вы спросите, и у вас есть причина для этого (к счастью, у меня хорошие отношения с сетевиками, и это не сложно сделать).
2. С отключенным отслеживанием DHCP на порту коммутатора им пришлось включить в коммутатор правило, согласно которому MAC-адресу X разрешено иметь IP-адрес Y. К сожалению, это побочный эффект также сказало, что MAC-адресу X разрешено иметь ТОЛЬКО IP-адрес Y. Для IP-псевдонимов необходимо, чтобы MAC-адресу X было присвоено два IP-адреса, поэтому это не сработало.

Возможно, эти проблемы были решены в конфигурации коммутатора, но, пытаясь сохранить хорошие отношения с сетевыми администраторами, я попытался найти другой путь. Наличие двух сетевых интерфейсов казалось следующим логическим шагом. К счастью, эта система Linux представляет собой виртуальную машину, поэтому я смог легко добавить второй сетевой интерфейс (без перезагрузки, я мог бы добавить - довольно круто). Спустя несколько нажатий клавиш у меня было два сетевых интерфейса, и оба извлекали IP-адреса из DHCP.

Но затем возникла проблема: сетевые администраторы могли видеть (на коммутаторе) запись ARP для обоих интерфейсов, но только первый сетевой интерфейс, который я вызывал, отвечал на эхо-запросы или любой вид трафика TCP или UDP.

После многих копаний и тычков, вот что я придумал. Кажется, что это работает, но также кажется, что много работы для чего-то, что кажется простым. Есть альтернативные идеи?

Шаг 1: Включите фильтрацию ARP на всех интерфейсах:

# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

Из файла network / ip-sysctl.txt в документации по ядру Linux:

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

Шаг 2: Реализация маршрутизации на основе источника

Я просто следовал указаниям http://lartc.org/howto/lartc.rpdb.multiple-links.html , хотя эта страница была написана с другой целью (работа с двумя провайдерами).

Предположим, что подсеть - 10.0.0.0/24, шлюз - 10.0.0.1, IP-адрес для eth0 - 10.0.0.100, а IP-адрес для eth1 - 10.0.0.101.

Определите две новые таблицы маршрутизации с именами eth0 и eth1 в / etc / iproute2 / rt_tables:

... top of file omitted ...
1    eth0
2    eth1

Определите маршруты для этих двух таблиц:

# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1

Определите правила, когда следует использовать новые таблицы маршрутизации:

# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1

Об основной таблице маршрутизации уже позаботился DHCP (и даже не ясно, что это строго необходимо в этом случае), но это в основном соответствует этому:

# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101

И вуаля! Кажется, все работает просто отлично. Отправка пингов на оба IP-адреса работает нормально. Отправка ping из этой системы в другие системы и принудительное использование ping для использования определенного интерфейса работает нормально ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). И самое главное, весь трафик TCP и UDP с / с любого IP-адреса работает должным образом.

Итак, еще раз, мой вопрос: есть ли лучший способ сделать это? Это кажется большой работой для, казалось бы, простой проблемы.

Обновление: решение, приведенное выше, оказалось неполным. Все работало нормально, если трафик оставался в той же подсети, но связь с другими подсетями через 2-й интерфейс не будет работать должным образом. Вместо того, чтобы вырыть большую дыру, я в итоге поговорил с сетевыми администраторами и заставил их разрешить несколько IP-адресов для одного интерфейса и использовал псевдонимы IP (например, eth0 и eth0: 0).

Да, лучший способ состоит в том, чтобы создать правильное экономическое обоснование и заставить их ослабить правила на коммутаторах, чтобы можно было иметь несколько IP-адресов на одном сетевом адаптере.