Недавно я столкнулся с ситуацией, когда мне понадобились два IP-адреса в одной подсети, назначенные одному хосту Linux, чтобы мы могли запускать два сайта SSL / TLS. Мой первый подход заключался в использовании псевдонимов IP, например используя eth0: 0, eth0: 1 и т. д., но у наших сетевых администраторов есть довольно строгие настройки безопасности, которые подавили эту идею:
Возможно, в конфигурации коммутатора был способ обойти эти проблемы, но в попытке сохранить хорошие отношения с администраторами сети я попытался найти другой способ. Следующим логическим шагом казалось наличие двух сетевых интерфейсов. К счастью, эта система 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).
Да, лучший способ - создать надлежащий бизнес-план и попросить их ослабить правила для коммутаторов, чтобы у вас было несколько IP-адресов на одной сетевой карте.