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

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

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

от ARP-спуфинга защититься хочет, наверное.

Держи

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

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

Во FreeBSD есть ifconfig staticarp

в таком случае +1 к man arp + `permanent' флаг.

man ip по слову noarp

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

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

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

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

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

Во FreeBSD есть ifconfig staticarp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. выше.

С чего это NAT вдруг костыль?

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

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

Есть. arptables.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо.

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

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

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

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

называть VRRP, CARP, CLUSTERIP костылями - это ты хорошо придумал, да

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

Взял пример с тебя :-P

Предлагаю завязывать.