a
можно провести небольшую аналогию с атакой арп-спуффинг, но то немного другое
Size: a a a
2020 March 07
МВ
вы путаете
Ещё раз: шлюз отправляет для клиентов 192.168.0.100 и 192.168.0.101 arp-whohas. Левый микротик с proxyarp отвечает: и 100 - это я, и 101 - это я!
Таким образом, на шлюзе будет две одинаковые арп-записи для адресов 100 и 101.
Таким образом, на шлюзе будет две одинаковые арп-записи для адресов 100 и 101.
a
да, всем. и клиенты у себе перепишут мак шлюза и все
a
проблема в том, что клиенты не знают, какой айпишка на шлюзе в данном случае
a
для них шлюз - 192,168,0,1 (условно). вот они просто перезапишут мак на нем и все
a
будет одна запись в арп таблице
m
проблема в том, что клиенты не знают, какой айпишка на шлюзе в данном случае
наверное опечатка: не айпи, а мак шлюза не знают
.
misha
арп запросы - широковещательные ff:ff:ff:ff:ff:ff
они всем уйдут
они всем уйдут
А это уже броадкаст шторм будет похоже в виду массовости
a
коллеги, вопрос. вы дебажили проблему арп-прокси?)
a
делали дамп трафика в этот момент?
VK
misha
арп запросы - широковещательные ff:ff:ff:ff:ff:ff
они всем уйдут
они всем уйдут
Щас я не признаю, что был не прав, но попробую. Могу быть не прав, факт.
МВ
Клиентам не надо знать. Провайдеру надо вовремя ловить совпадения на шлюзе. Ну и разумеется настраивать свитчи: port isolation как минимум и не кидать больше одного свитча в один VLAN
a
штрома не будет
a
то другое
a
не будет совпадений маков.
МВ
не будет совпадений маков.
a
если совпадение маков где-то на сети, то это петелька в чистом виде!
.
На отдельно взятом порту возрастёт количество арп
МВ
если совпадение маков где-то на сети, то это петелька в чистом виде!
Совпадения не в FDB, а в ARP
.
А это уже как минимум аномалии