LINUX.ORG.RU
решено ФорумAdmin

Как запретить arp discover?


1

1

Подскажите, как можно сконфигурировать интерфейс, чтобы машина не отсылала ARP-запросы для выяснения мак-адресов? Предполагается, что все нужные соответствия MAC-IP будут внесены статически. При этом нужно, чтобы эта машина сама нормально отвечала на ARP-запросы по поводу её собственного IP-адреса.

Если сделать ifconfig <if> -arp , то машина перестает отвечать на ARP-запросы.

Есть способ, кроме iptabes/ipfw (мне на FreeBSD надо вообще-то, но не принципиально).

arp -f /путь/к/файлу
man arp

lnx ()

мне на FreeBSD надо вообще-то, но не принципиально

Во FreeBSD есть ifconfig staticarp

lnx ()

man ip по слову noarp

zolden ★★★★★ ()

Можно всем сразу ответить?

в чём сокральный смысл данной манипуляции?

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

http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disabl..

Это читал. Только вроде бы не в тему. Или покажите какую комбинацию этих параметров следует использовать. Ибо я вижу, что это немного не о том всё. Хотя мне и предложили решение для FreeBSD, не факт, что в дальнейшем не понадобится такое же для линукса.

Во FreeBSD есть ifconfig staticarp

Вот за это спасибо большое. Как часто бывает, решение под носом, что называется, а не докопался исключительно по невнимательности.

А ко всем предложившим static arp вопрос: как это воспрепятствует отправке запросов для адресов, которые компьютер не знает и знать не должен? Забить их какими-нибудь нулевыми маками? А если это сеть /16, к примеру? Есть, правда, ещё вариант - поиграться с маршрутами типа blackhole. Интересно, как оно отреагирует, если всю подсеть, в которую выставлен интерфейс, объявить чёрной дырой? А разрешенные IP-шки открывать индивидуально. Или наоборот, смотря чего больше. Как вообще, линукс прожует наличие пары тысяч маршрутов?

shamus24 ()
Ответ на: комментарий от shamus24

Интересно, как оно отреагирует, если всю подсеть, в которую выставлен интерфейс, объявить чёрной дырой? А разрешенные IP-шки открывать индивидуально. Или наоборот, смотря чего больше. Как вообще, линукс прожует наличие пары тысяч маршрутов?

Да нормально всё будет. Но это не оправдывает костыльность твоего решения.

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Но это не оправдывает костыльность твоего решения.

Современные сети на сплошных костылях и живут. Куда ни посмотри - IP Unnumbered, DHCP snooping, IP Source Guard, Proxy ARP, NAT - что из этого не костыль? Да даже простейшая фича, испокон веков во всех свичах присутствует, и про которую я даже не помню как называется - когда широковещательный пакет пересылается только в тот порт, в котором адресат живёт - и то уже костыль, по большому счету.

А если на Multicast посмотреть, то оно, по-моему, вообще без костылей не существовало никогда. Причём там не просто костыли, там целые биомеханические протезы с нанотехнологиями и спутниковой связью.

shamus24 ()

А ко всем предложившим static arp вопрос: как это воспрепятствует отправке запросов для адресов, которые компьютер не знает и знать не должен? Забить их какими-нибудь нулевыми маками? А если это сеть /16, к примеру? Есть, правда, ещё вариант - поиграться с маршрутами типа blackhole. Интересно, как оно отреагирует, если всю подсеть, в которую выставлен интерфейс, объявить чёрной дырой? А разрешенные IP-шки открывать индивидуально. Или наоборот, смотря чего больше. Как вообще, линукс прожует наличие пары тысяч маршрутов?

ну ты уж определись, че те надо, если заявил, что

Предполагается, что все нужные соответствия MAC-IP будут внесены статически.

lnx ()

читай основы сетей и больше не считай себя пупом сетей.

lnx ()
Ответ на: комментарий от shamus24

там не просто костыли, там целые биомеханические протезы с нанотехнологиями и спутниковой связью

достойно квотезов!

Komintern ★★★★★ ()
Ответ на: комментарий от lnx

ну ты уж определись, че те надо, если заявил, что

Предполагается, что все нужные соответствия MAC-IP будут внесены статически

Значительная часть ip-адресов из диапазона в конкретный момент времени может оказаться недоступной (компьютеры выключены). В момент пробного включения были недоступны все. А трафик на них сыпется, невзирая на, потому как он из интернета. Именно эти ARP-запросы для выяснения мак-ов недоступных адресов и составляют проблему. С доступными проще - он один раз спросил и 20 минут потом молчит. Вот я и раздумываю, что эффективнее - забивать недоступные IP-адреса фиктивными мак-адресами в ARP-таблице, или блокировать их путём указания blackhole-маршрутов?

Напоминаю, что статические ARP- это ещё и безопасность, то есть будет реализовано в любом случае. А раз уж компьютер и так знает все нужные MAC-и, то, в общем, логично исключить использование широковещательных запросов arp для их изучения.

читай основы сетей и больше не считай себя пупом сетей.

Те, кто так считает, вряд-ли здесь что-то спрашивают.

shamus24 ()
Ответ на: комментарий от shamus24

IP Unnumbered, DHCP snooping, IP Source Guard, Proxy ARP, NAT - что из этого не костыль?

из всего этого костыль только NAT, и то не от хорошей жизни придуманный

Pinkbyte ★★★★★ ()
Ответ на: комментарий от shamus24

Первое - защита от подделок и попыток использовать нераспределенные адреса,

Включить port-security на свичах.

второе - уменьшить количества широковещательного трафика в сети.

Порезать сеть на VLAN-ы.

А если это сеть /16, к примеру?

См. выше.

frob ★★★★★ ()
Ответ на: комментарий от frob

С того что хоть сколько нибудь сложный протокол(сложнее HTTP) уже не может работать с NAT без доп. костылей-подпорок. А еще NAT нарушает прозрачную организацию сети, скрывая кучу адресов за одним(если нужно закрыть доступ, правильнее это делать файрволлом). Однако, пока не перешли на IPv6, приходится жрать что дают...

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)

Есть способ, кроме iptabes/ipfw (мне на FreeBSD надо вообще-то, но не принципиально).

Есть. arptables.

funky ()
Ответ на: комментарий от Pinkbyte

сколько нибудь сложный протокол

Видимо это надо читать как «протокол, авторы которого дублируют информацию с IP layer в Application layer».

уже не может работать с NAT без доп. костылей-подпорок.

Давай-ка уточним: костыльно сделанный протокол не сможет работать с NAT — это вина NAT, да?

NAT не предполагает и не требует PAT.

frob ★★★★★ ()
Ответ на: комментарий от frob

костыльно сделанный протокол не сможет работать с NAT — это вина NAT, да?

Только почему-то таких протоколов вагон, причем все стандартизированы. Чуешь, что это значит? Только не надо говорить мне, что те, кто придумали и одобрили эти протоколы - идиоты. Большая часть известных мне сетевиков считает NAT вынужденной мерой, к которой пришлось прибегнуть от безысходности(читай - костылем), потому что кто-то в свое время хреново спланировал распределение адресного пространства.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

потому что кто-то в свое время хреново спланировал

Был у меня на тренинге один крендель, который всё удивлялся, что RIP так глупо сделан. Так много гениев вокруг... и почему это они в основном критикуют разработанное до их рождения, а не монстрируют свои истинно правильные разработки?

Не надо путать зелёное с длинным: NAT позволяет заменить в проходящем пакете несколько значений на другие и при необходимости заменить значения на соответствующие в ответном пакете. Ничего плохого в этом нет.

Чуешь, что это значит?

Это означает, что те кто их разработал не смогли (или не захотели) обойтись без костылей. Больше ничего.

Большая часть известных мне сетевиков

Поинтересуйся у них как без костылей организовать балансировку нагрузки между серверами. Или как объединить купленную сеть (10/8) с имеющейся (10/8).

frob ★★★★★ ()
Ответ на: комментарий от frob

один крендель, который всё удивлялся, что RIP так глупо сделан.

Я тебе скажу тоже самое. Вот ты, к примеру, можешь сходу назвать преимущества RIP(не RIP-2 или RIPng) перед, скажем OSPF? Только не надо загибать про «простоту эксплуатации». Бесконечная метрика в 16 хопов - это лол. Я понимаю, если это использовать в домашней сети или в сети малого предприятия. Но когда кол-во сегментов растет, масштабируемость у RIP откровенно хреновая...

NAT позволяет заменить в проходящем пакете несколько значений на другие и при необходимости заменить значения на соответствующие в ответном пакете. Ничего плохого в этом нет.

учитывая клинических дебилов, которые любят его юзать ВМЕСТО файрволла(особенно на железках, которых не обучили conntrack-у или его аналогах для тех же SIP,H.323, FTP и т.д.) - ну ты понел, с чем мне приходится сталкиваться, да?

Поинтересуйся у них как без костылей организовать балансировку нагрузки между серверами

VRRP. На худой конец - CARP. Никаких костылей я здесь не вижу.

Или как объединить купленную сеть (10/8) с имеющейся (10/8)

Постепенная смена адресации, посегментно - от ядра сети к нижестоящим сегментам. При правильной организации сети(использовании DNS везде где можно) - не такая уж и проблема. Если где-то сеть организована хреново - отличная причина сделать реорганизацию. Да, это займет время - зато профит в обслуживании потом будет налицо. И да, надеюсь ты не имеешь ввиду что 10/8 с каждой стороны - это 1 сегмент? :-)

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от frob

Это означает, что те кто их разработал не смогли (или не захотели) обойтись без костылей.

Скорее всего это было банально невозможно - обойтись без включения информации об IP в протокол. Это конечно не очень хорошо с архитектурной точки зрения, признаю, но если эти протоколы получили широкое распространение - с этим приходится как-то жить. И по мне проще убрать NAT везде, где можно, чем танцевать вокруг различных его реализаций.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Я тебе скажу тоже самое.

Чтобы не отклоняться от темы, будет достаточно, если ты скажешь почему 25 лет назад ты не сказал об этом в комментариях к RFC.

учитывая клинических дебилов

Это отличный аргумент. Очень веский. Но причём здесь NAT?

VRRP. На худой конец - CARP. Никаких костылей я здесь не вижу.

Конечно не видишь. Расскажи-ка, как (на толстом конце) VRRP позволит тебе БАЛАНСИРОВАТЬ нагрузку между СЕРВЕРАМИ. Смотри не увлекись костылетворчеством.

Постепенная смена

Забыл сказать... Множества гениев и множества теоретиков имеют пересечения.

frob ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Это конечно не очень хорошо с архитектурной точки зрения

Костыль! Костыль! Подавился костылём! :-P

признаю, но если эти протоколы получили широкое распространение

Широкораспространённый костыль!

- с этим приходится как-то жить.

Вот видишь... Если тебя дёргать и толкать, то ты начинаешь думать =)

frob ★★★★★ ()
Ответ на: комментарий от shamus24

Первое - защита от подделок и попыток использовать нераспределенные адреса,

1.Феерично... arp протокол L2 уровня, обмануть - замена/подмена MAC как два байта переслать, ну про IP-шник я думаю говорить не надо, да?

второе - уменьшить количества широковещательного трафика в сети.

2.UDP - это вообще о чем? Про multicast слышали?

Пробное включение показало, что одна такая машина его генерирует ну очень много.

Сама по себе ОС или сетевая карта UDP/Multicast генерировать в «таких количествах» не будет, так что изучаем свою ОС на предмет стороннего генератора трафика.

Подробностей не дам, извините — сеть сложная, схема включения тоже.

Ну конечно же, развесовка-то по графам идет, никак AS настраиваешь?

А если это сеть /16

Кто же тебе такому-то её вручил?!

Интересно, как оно отреагирует, если всю подсеть, в которую выставлен интерфейс, объявить чёрной дырой? А разрешенные IP-шки открывать индивидуально.

Чем тебя ACL не устраивают?

Или наоборот, смотря чего больше. Как вообще, линукс прожует наличие пары тысяч маршрутов?

Ну всё зависит от того как ты роуты пропишешь.

Гы-ы-ы, даю $1000(на основании первого вопроса) (ставка 1:6) что ты не сдюжишь.

e000xf000h ()

Подскажите, как можно сконфигурировать интерфейс, чтобы машина не отсылала ARP-запросы для выяснения мак-адресов?

Эх-х, завидую, первый раз в первый класс. Изучаем канальный уровень.

e000xf000h ()
Ответ на: комментарий от frob

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от frob

почему 25 лет назад ты не сказал об этом в комментариях к RFC.

потому что родился ~24 года назад - такой ответ тебя устроит? :-)

как (на толстом конце) VRRP позволит тебе БАЛАНСИРОВАТЬ нагрузку между СЕРВЕРАМИ.

Поясни, что ты имеешь ввиду под «на толстом конце»?

Забыл сказать... Множества гениев и множества теоретиков имеют пересечения.

учитывая что я принимал участие в подобной миграции около 15 раз из-за криво спроектированной сети, присоединения филиалов и прочего, мой ответ тебе, теоретик - толсто!

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от shamus24

Как вообще, линукс прожует наличие пары тысяч маршрутов?

Нормально отреагирует, всё одно маршруты кешируются. А вобще, может вам нужно использовать arpd (может даже пропатчив его)?

mky ★★★★★ ()
Ответ на: комментарий от Pinkbyte

потому что родился ~24 года назад - такой ответ тебя устроит? :-)

Ну, я как-то так и предполагал. Отмотай обратно и прикинь:
- какого размера сеть можно было себе представить в то время
- что было бы в такой сети маршрутизатором
- как бы оно булькало, сумей кто-то на таком завести OSPF.

Поясни, что ты имеешь ввиду под «на толстом конце»?

Только то, что на худом конце у тебя CARP.

frob ★★★★★ ()
Ответ на: комментарий от e000xf000h

UDP - это вообще о чем? Про multicast слышали?

И в самом деле феерично. ARP Discovery — broadcast.

frob ★★★★★ ()
Ответ на: комментарий от frob

какого размера сеть можно было себе представить в то время

640 килобайт...

как бы оно булькало, сумей кто-то на таком завести OSPF.

То, что RIP потребляет меньше ресурсов, не означает его нужности использования СЕЙЧАС, на нормальных маршрутизаторах.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

не означает его нужности использования СЕЙЧАС

Вместе поищем где я что-нибудь по этому поводу говорил или подождём что твои знакомые сетевики про LB скажут?

frob ★★★★★ ()

эээ, я такие траблы видел только в сетях /8 с 10мегабитной сетью. Что-то ты не то наворотил раз отгребаешь такие траблы - или ищи неправельно работающее оборудование. arp фактически особо не влияет на пропускную сети. но если у вас любят использовать всякие netview - ССЗБ

visual ★★★ ()
Ответ на: комментарий от frob

тебе не понравился человек, который утверждал что RIP говно. В текущих реалиях(если не принимать в расчет RIP2) - это так. Дальнейшую логическую цепочку построишь?

И да, по поводу LB - есть еще CLUSTERIP, да...

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

который утверждал что RIP говно

который всё удивлялся, что RIP так глупо сделан.

Разницу понимаешь?

И да, по поводу LB - есть еще CLUSTERIP, да...

И да, докажем что костыль NAT не нужен заменив его на три других костыля...

frob ★★★★★ ()
Ответ на: комментарий от frob

Костыль костылю рознь. Если ты считаешь применение технологии для кластеризации, которая специально разрабатывалась именно с этой целью, костылем, то ОК.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Если ты считаешь применение технологии замены адреса в пакете, которая специально разрабатывалась для замены адреса в пакете, костылём, то ОК.

frob ★★★★★ ()
Ответ на: комментарий от frob

Только то, что на худом конце у тебя CARP.

Я вживую дела с VRRP и CARP еще не имел, только почитал и в общем сложил представление о принципе его работы. Но все равно не пойму как будет балансироваться нагрузка в таком случае:

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

xscrew ★★ ()
Ответ на: комментарий от frob

Я не считаю применение NAT костылем, когда это оправданно. Я считаю САМУ процедуру замены адреса в пакете костылем. Ферштейн?

Pinkbyte ★★★★★ ()
Ответ на: комментарий от xscrew

CARP и VRRP обеспечат отказоустойчивость маршрутизации для клиентов, CLUSTERIP - для конечного приложения на сервере

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Значит я верно понял, что сбалансировать нагрузку между серверами не выйдет, используя xRP.

Спасибо.

xscrew ★★ ()
Ответ на: комментарий от Pinkbyte

Я думаю, что тебе надо перечитать твоё высказывание, подумать что же ты на самом деле хотел сказать и исправить. Компрэнэ?

frob ★★★★★ ()
Ответ на: комментарий от xscrew

Обычная схема

... load balancer с какими-то виртуальными адресами/портами и сервера находящиеся где угодно. VRRP, CARP, CLUSTERIP и прочие костыли тут совершенно не при чём.

frob ★★★★★ ()
Ответ на: комментарий от frob

Хорошо, давай обобщу еще раз: «Я против технологии NAT, потому что суть данной технологии противоречит идее сетевой прозрачности, отсюда возникает куча изъянов как в техническом, так и в организационном плане при ее применении». Так я яснее выразился?

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

На колу мочало, начинай сначала...

frob ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.