Два сетевых интерфейса и два 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 -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). И самое главное, весь трафик TCP и UDP на /с любого из IP-адресов работает как ожидалось.


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


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

21 голос | спросил Scott Duckworth 30 32011vEurope/Moscow11bEurope/MoscowWed, 30 Nov 2011 03:04:49 +0400 2011, 03:04:49

1 ответ


8

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

ответил Zypher 30 32011vEurope/Moscow11bEurope/MoscowWed, 30 Nov 2011 03:10:34 +0400 2011, 03:10:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132