[kaktak]

Схема vlan на район, потребность белых ip в районах заранее не известна, а общее их (ip) кол-во сильно ограничено, поэтому решил, что лучший выход - ip unnumbered.

Вопрос есть ли грабли? Например с прокси арп.

Пример:

10.2.2.1/32 - ip на моем linux роутере

10.2.2.2/32 и 10.2.2.3/32 - ip абонентов, причем в одном влане (районе)

Предположим 10.2.2.2 решил пообщаться с 10.2.2.3, шлет arp who has 10.2.2.3 в свой бродкаст домен. Понятно, что 10.2.2.3 ответит ему, но станет ли ему отвечать 10.2.2.1? И если да, то есть ли в этом какие-то проблемы? Сильно ли возрастает нагрузка на роутер при использовании арп прокси? Я понимаю, что век п2п прошел и трафик между абонентами очень мал, но есть же еще вирусная активность и прочее говноПО, которое будет переодически опрашивать весь свой бродкаст домен.

[NiTr0]

Какой бродкаст домен для /32 подсети? :)

Абону выдавать адрес /32 и маршрут на гейтвей через 0.0.0.0, + дефолт маршрут через гейтвей. Винда - и так прожует, линь - без доп. маршрута жевать откажется.

Грабли могут вылезти на роутерах-мыльницах. Гарантированно вылезут на realtek-based. На остальных - в зависимости от кривости ПО вендора.

[kaktak]

упс не то написал, на роутере 10.2.2.1/32 (плюс маршруты для каждого абонента), а абонам пранирую выдавать обычные 10.2.2.2/24 etc

Edited April 27, 2013 by kaktak

[disappointed]

но станет ли ему отвечать 10.2.2.1

А зачем ему отвечать 10.2.2.2-му, его же не спрашивали про его мак, запрос был arp who has 10.2.2.3,

он и ответит ему.

 

Вообще предполагается, что до клиентов идёт пачка vlan-ов, каждый из них получает адрес с короткой маской всего сегмента,

а реально находится в полностью изолированном vlan-е который приземлён на маршрутизаторе с включённым прокси арп.

[kaktak]

но станет ли ему отвечать 10.2.2.1

А зачем ему отвечать 10.2.2.2-му, его же не спрашивали про его мак, запрос был arp who has 10.2.2.3,

он и ответит ему.

 

так ведь на интерфейсе 10.2.2.1 включен proxy_arp. Соответственно, когда он получит arp who has 10.2.2.3 (а он получит, ибо броадкаст), то попытается найти хозяина этого ip в своих присоединенных сетях и если найдет, ответит arp'ом со своим маком. Я ведь правильно понимаю механизм работы proxy arp? Вопрос будет ли роутер выполнять перечисленные выше действия, если искомый мак находится за тем же интерфейсом, что и ищущий?

Edited April 27, 2013 by kaktak

[DVM-Avgoor]

Что-то мне подсказывает, что все зависит от маски на интерфейсе с proxy-arp. Если там /32 то отвечать будет на все.

[disappointed]

(а он получит, ибо броадкаст)

А ну да, найдёт, ответит. В арпкеше запрашивающего останется мак маршрутизатора от второго ответа.

[kaktak]

В арпкеше запрашивающего останется мак маршрутизатора от второго ответа.

 

либо мак настоящего владельца 10.2.2.2 в зависимости от того кто из них ответит последним? В любом случае все это работает?

[disappointed]

Ага, но наверно чаще мак маршрутизатора, всё же он будет отвечать позднее.

Если вы не будете гнать пачки vlan-ов до клиентов, то как решите проблему безопасности этого сегмента/района?

[kaktak]

Просто в реале на том же интерфейсе с ip unnumbered будет и обычная серая подсеть (в примере 8.8.8.1/32 - шлюз для белых ip по технологии ip unnumbered, а 10.10.10.1/24 шлюз "обычной" сети):

eth0.2  Link encap:Ethernet  HWaddr 00:21:91:8a:ce:46  
         inet addr:10.10.10.1  Bcast:10.10.10.255  Mask:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:16609 errors:0 dropped:0 overruns:0 frame:0
         TX packets:35309 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0 
         RX bytes:850294 (830.3 KiB)  TX bytes:51641642 (49.2 MiB)

eth0.2:1 Link encap:Ethernet  HWaddr 00:21:91:8a:ce:46  
         inet addr:8.8.8.1  Bcast:8.8.8.1  Mask:255.255.255.255
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric

 

При этом я понятия не имею о кол-ве трафика внутри сети 10.10.10.0/24, соответственно не хотелось бы, чтобы он весь внезапно пошел через маршрутизатор.

Может как то фильтровать arp ответы маршрутизатора? Разрешать с этого интерфейса только arp reply 10.10.10.1 and 8.8.8.0/24. Такое вообще возможно? )

 

Если вы не будете гнать пачки vlan-ов до клиентов, то как решите проблему безопасности этого сегмента/района?

 

доступ управляемый, в влане примерно по 100 маков (не более /24 на vlan). на портах acl и прочее фильтры типа лупдетект, трафик контроль etc.

[disappointed]

А каким образом клиенты будут получать адреса? Вернее как будет идентифицироваться порт со стороны DHCP.

Невозможность работы с другого адреса решается прямо на порту ацл-ом? Этими фильтрами рулит биллинг?

 

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

[kaktak]

А каким образом клиенты будут получать адреса? Вернее как будет идентифицироваться порт со стороны DHCP.

Невозможность работы с другого адреса решается прямо на порту ацл-ом? Этими фильтрами рулит биллинг?

 

dhcp, на портах пока ip-mac-binding, в будущем планирую выдавать по option 82 + dhcp snooping. И в том и в другом случае автоматически создается acl, запрещающий работу с невалидных ip. Фильтрами рулит самописный обвес к биллингу.

Edited April 27, 2013 by kaktak

[kaktak]

Провел несколько экспериментов. В общем, arp-proxy на linux не ищет в том сегменте откуда пришел запрос и это меня полностью устраивает =)

Чтобы это изменить, есть параметр proxy_arp_pvlan, в этом случае linux отвечает в сегмент откуда пришел arp who has cвоим маком на все запросы.