Netdiscover работает ...
активно отправляя запросы arp
Запросы Arp не пересекают шлюзы. Во-первых, на машинах Linux мы активируем пересылку IPv4 , но пакеты IPv4 являются объектами OSI-Layer 3, а запросы ARP являются объектами OSI-Layer 2, так что нигде в ядре Linux нет инструкции для пересылки запросов ARP на другой интерфейс. ,
Это как раз ваш случай: как только запрос ARP достигает интерфейса хоста, он будет отброшен, поскольку IP-адрес, для которого требуется MAC, не соответствует интерфейсу. Также запрос не будет перенаправлен на другой интерфейс по вышеуказанной причине. Следовательно, ваш хост (правильно) отбрасывает запрос ARP, который останется без ответа. Это объясняет сбой Netdiscover в вашей настройке.
Вышеуказанный сбой не связан с тем, что в VMWare нет подходящего шлюза между различными сетями. Даже пренебрегая невозможностью пересылки серверами Linux чего-либо, кроме объектов IPv4 (т. Е. При условии, что у вас есть шлюзы / маршрутизаторы, отличные от Linux), наиболее распространенным поведением шлюзов является ответ на запросы ARP удаленных хостов с их собственным MAC-адресом, см. экземпляр здесь под операцией ARP для удаленного хоста. Другими словами, нет восходящей цепочки запросов ARP, пока MAC-адрес удаленного хоста не сопоставлен с предоставленным IP. Кроме того, минимальное поведение, описанное выше (возвращение MAC-адреса локального шлюза), не является распространенным.
Все это можно легко проверить: на компьютере Debian
sudo apt-get install iputils-arping
sudo arping -f -c 1 -w 5 -I eth0 8.8.8.8
и что-то похожее на это на всех других ОС. Вы увидите, что вы не получите ответов. Вы также можете использовать traceroute для поиска IP-адресов некоторых ваших собственных шлюзов восходящего направления; команда
sudo arping -f -c 1 -w 5 -I eth0 IP_of_Upstream_Gateway
также останется без ответа.
Чтобы протестировать Netdiscover на вашей установке, вы должны будете разместить все свои виртуальные машины, злоумышленников и злоумышленников в одной подсети. Тогда ARP будет работать.
