Два интерфейса в одной подсети

Два интерфейса в одной подсети

Недавно я столкнулся с ситуацией, когда мне понадобилось два 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 для всех интерфейсов:

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

Шаг 2. Внедрение маршрутизации на основе источника

В основном я просто следовал указаниям Ссылка , хотя эта страница была написана с другой целью (имея дело с двумя интернет-провайдерами).

Предположим, что подсеть 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:

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

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

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

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

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

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

Читайте также:  Как вручную обновить базы доктор веб 10

Добрый вечер, уважаемые коллеги. Прошу Вашей помощи с интересным вопросом.
Есть роутер — он в локалку смотрит двумя физическими сетевыми картами, которые воткнуты в единый свич (в соседние порты).
ОС: Debian 8.
Карточкам я назначил айпишники 192.168.0.1 (eth1) и 192.168.0.200 (eth2)
Также в этот роутер подключены два провайдера.
При помощи iptables я включил masquerade из подсети 192.168.0.0/24 во все стороны.
соответственно если клиент на своей стороне ставит в качестве шлюза IP адрес любой из этих карточек (eth1,2) он получает доступ в интернет через default gw на роутере.
Задача была поставлена — чтобы при установке на рабочей станции клиента в качестве шлюза 192.168.0.200 интернет шел через второго провайдера.

было решено при помощи трех строчек в iproute2

echo 1 2PR >> /etc/iproute2/rt_tables
ip rule add iif eth2 lookup 2PR
ip route add default via 10.0.0.1 table 2PR

где 10.0.0.1 — соответственно шлюз второго провайдера
теперь когда юзер ставит в качестве шлюза 192.168.0.200 трафик ходит через второго прова (проверял на 2ip.ru).

но! есть два интересных затыка, с которыми я не могу разобраться.
1) при диагностике маршрута через traceroute наблюдаю что шлюз 192.168.0.1. даже если на клиенте в ipv4-конфигурации прописан 192.168.0.200. Как это происходит?
2) Поднял на обеих интерфейсах DHCP сервер, который выдает в качестве шлюза первого провайдера (eth 1 , 192.168.0.1), но при подключении например мобильного телефона через wifi (есть еще точка доступа с 4 LAN портами) както трафик бегает то через первого то через второго провайдера, что тоже ооочень странно.
3) Антивирусы у юзеров матеряться что в локалке 2 шлюза, да еще и с поднятым DHCP.
В чем может быть причина такого поведения?

Читайте также:  My passport ultra разборка

Наконец появилась и возможность и необходимость разобраться с маршрутизацией и сетями. В один свитч воткнуты машины с ип-шниками (допустим) 192.168.0.124 и 192.168.1.124 , и в тот же свитч воткнут вин сервер. У сервера два алиаса на одну сетевуху, допустим: 192.168.0.10/24 и 192.168.1.10/24. У машин шлюз по умолчанию — этот вин сервер. И что я только не пробовал с таблицей на сервере — не направляет он трафик из одной сети в другую. Помогите, чем можете. Какая еще информация нужна? Собственно, причина нашлась. Я не указал на машине во второй подсети шлюз по умолчанию.

1 ответ 1

Советую так никогда не делать, если свитч не имеет VLAN (иначе лишний широковещательный трафик из другой сети будет лететь во все остальные, а VLAN ограничит его в своем широковещательном домене).

Если сделать 192.168.0.10/23, то никакая маршрутизация не нужна. Машины, естественно, тоже необходимо переконфигурировать на 192.168.0.0/23 и выдать айпишники из диапазона 192.168.0-1.1(0)-254(5). Но шлюзом для всех машин все равно останется 192.168.0.10. В данном случае с обыкновенным свитчем будет работать.

Если необходимо все же маршрутизацию, тогда вопрос:

А между компами в одной сети пакетики бегают?

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

UPD

В данной записи от Майкрософт говорится, о том, что необходимо сделать дабы включить маршрутизацию в Windows (именно на сервере, на главном маршрутизаторе, на обычных машинах толку от данной операции никакого).

UPD2

Так как человек молчит, могу предположить, что решение все же нашлось.

Ссылка на основную публикацию
Adblock detector