Ubuntu Linux - кілька NIC, однакова локальна мережа… ARP-відповіді завжди виходять з одного NIC


16

У нас є інтернет-сервіс AT&T U-Verse, який має надзвичайно непомітний шлюз DSL.

У нас є 5 IP-адрес (мережева маска 248), але шлюз не може робити нічого, крім одного IP -> єдиного відображення MAC-адреси.

У нас є одна машина брандмауера, і ми переспрямовуємо різні комбінації IP / портів у різні місця всередині DMZ.

Поки що наше рішення - мати на брандмауері віртуальну машину VMWare з 4 додатковими NIC, щоб отримати інші 4 IP-адреси ... однак у нас є проблема.

В основному шлюз робить ARP-пінг, щоб перевірити, чи відповідає IP на очікуваному MAC. Із 4 NIC в одній локальній мережі Linux відповідає на запити ARP для ВСІХ IP-адрес за допомогою одного інтерфейсу. Це не те, чого очікує шлюз, і це зіпсує 3 інші NIC. Шлюз відмовляється направляти вхідний трафік для IP-адрес, де результати ARP-пінгу не є очікуваним MAC.

Як ми можемо отримати відповіді ARP для IP-адреси eth0, щоб вийти eth0, IP-адреса eth1, щоб вийти eth1, тощо?

EDIT

Відповідь Крістофера Кашелла не працює в цій ситуації. Я покладав великі надії, читаючи це, але ... ні.

EDIT 2

Вирішено! Дивіться мою відповідь нижче.


PS - жодних коментарів "без падіння" ... U-Verse становить 18 Мбіт / с, порівняно з усіма іншими 3 Мбіт / с або дуже ненадійними 10 Мбіт / с через кабель
Даррон

@dblack: Ви забули додати свою відповідь :)
Mihai Limbăşan

Сайт api.recaptcha.net на деякий час був вниз. Відповідь зараз.
darron

Відповіді:


13

Обране вами рішення працює, але є альтернативи, які не включають аргументи. (Спочатку Крістофер Кашелл був на правильному шляху, але його відігнав смерд.)

Коротше кажучи, ви хочете встановити ці параметри:

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Вони повинні бути доступні під час використання сучасного ядра Linux серії 2.6. Перевірте і переконайтеся, що у вашій системі існує "/ proc / sys / net / ipv4 / conf / / arp_announce" та / proc / sys / net / ipv4 / conf / / arp_ignore ".

Параметр 'arp_filter' працює лише тоді, коли різні ваші IP-адреси поділяють сегмент локальної мережі, але використовують іншу підмережу IP. Якщо вони поділяють IP-підмережу, вам також потрібно використовувати "arp_ignore" та "arp_announce", як зазначено вище.

(Я вважаю, що вам може знадобитися також встановити "arp_filter" назад на "0".)


Що сталося з arp_filter? Це було раннє (2003?) Рішення проблеми ARP, але воно, здається, не працює як описано, принаймні, на Centos 5. arp_ignore та arp_announce здаються гарними.
pcapademic

Здається, таке рішення працює, лише на рівні ARP. Без додаткових налаштувань маршруту брандмауер все ще може обрати неправильну вихідну карту (та MAC) для власного вихідного IP-трафіку, але (як і раніше) завжди отримуватиме вхідний IP-трафік на правій карті, що призводить до асиметричного розгляду шляху та rp_filter.
AB

8

Гаразд, ось рішення. По-перше, резюме:

Ось мій базовий мережевий план:

 eth0 10.10.10.2 netmask 255.255.255.248
 eth1 10.10.10.3 netmask 255.255.255.248
 eth2 10.10.10.4 netmask 255.255.255.248
 eth3 10.10.10.5 netmask 255.255.255.248

Всі інтерфейси перекриваються. Це технічно неправильно, і джерело всіх моїх неприємностей ... але я маю це робити через цей німий житловий шлюз.

По-перше, трансляція запитів ARP стосується всього цього. Оскільки всі 4 IP-адреси є дійсними локальними адресами, всі 4 інтерфейси намагаються відповісти.

1) встановити аргументи . Додайте це місце десь під час завантаження ( /etc/rc.local тут):

arptables -F INPUT
arptables -A INPUT -i eth0 --destination-ip ! 10.10.10.2 -j DROP
arptables -A INPUT -i eth1 --destination-ip ! 10.10.10.3 -j DROP
arptables -A INPUT -i eth2 --destination-ip ! 10.10.10.4 -j DROP
arptables -A INPUT -i eth3 --destination-ip ! 10.10.10.5 -j DROP

Це запобіжить переходу трансляцій у неправильний інтерфейс. Отже, правильний інтерфейс тепер стане єдиним респондентом.

Це само по собі недостатньо. Наступний біт - це проблема таблиці ARP. На запитувальному ПК, ймовірно, вже є запис таблиці ARP, і тому Linux збирається використовувати пов'язаний з цим інтерфейс. Доки термін запису таблиці ARP не закінчиться, він буде намагатися надсилати відповіді ARP за допомогою інтерфейсу цього запису, а не того, який пов'язаний із запитом ARP.

Опція sysctl rp_filter, схоже, відхиляє вихідні пакети відповідей ARP, якщо вони не відповідають інтерфейсу. Так...

2) Вимкнути rp_filter .

В Debian / Ubuntu, це означає закомментировать дві rp_filter лінії в /etc/sysctl.d/10-network-security.conf .

Ця опція була ввімкнена з якоїсь причини, а саме - щоб запобігти атакам підробки між інтерфейсом. Я читаю, що він підтверджує, що пакет легальний для інтерфейсу, який він входить або виходить (шляхом заміни MAC та IP-адрес і перевіряє, чи все ще рухається через той самий інтерфейс). Отже, як правило, було б погано вимкнути це. У моєму випадку всі інтерфейси є в одній мережі ... так що перевірка насправді не має значення.

Якщо я додам інший інтерфейс і мені потрібен захист від підробки, можливо, я можу створити деякі записи arptables / iptables, щоб зробити те саме.


5

Це пов'язано з тим, як Linux обробляє IP-адреси та NIC. В основному, вона розглядає IP-адресу так, як ніби вона належить до поля, а не лише конкретного NIC. У результаті ви можете отримати відповіді ARP з IP-адрес на інтерфейсах, яких ви не очікували.

Рішення - це sysctl варіант. Наскільки я пам'ятаю, ви шукаєте:

net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1

Це вирішить для вас проблему. Просто додайте їх до /etc/sysctl.conf та запустіть ' sysctl -p' (або запустіть кожен рядок як аргумент до ' sysctl -w'.

Це призведе до того, що Linux відповість лише на запити ARP в інтерфейсі, якому фактично призначена IP-адреса.


хм ... на жаль, схоже, це не працює. Я вставив це в sysctl.conf, запустив sysctl, навіть перезавантажив, без змін. Я можу задати параметри в / proc і побачити, що вони встановлені, але якщо я аргументуюсь з іншого поля, всі відповіді надходять з одного MAC. Інтерфейси - це все в одній мережі (та ж трансляція тощо) ...
darron

1
Це правильне рішення, якщо інтерфейси є в одній мережі, але мають адреси в різних підмережах. Підтверджена робота.
Аластер Ірвін

1

Прийнята відповідь у поєднанні з цим: http://www.linuxquestions.org/questions/linux-networking-3/multiple-interfaces-all-traffic-flows-through-just-one-538701/

де статичні маршрути використовуються для спілкування лише з потрібними IP-адресами через певні інтерфейси, створили потужне і просте рішення подібної проблеми.


0

Чи можете ви з’єднати шлюз і мати брандмауер обробляти IP-адреси?


наскільки я це розумію, ні ... але хтось, будь ласка, виправить мене, якщо я не прав.
darron
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.