Назад | Перейти на главную страницу

Лучший способ определить, работают ли IP-адреса в подсети в Linux

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

Сначала я перебираю список доменных имен с помощью этой команды:

sudo nmap -sS -O -v oN $filename $name

$filename мой выходной файл для этого IP и $name - это доменное имя, которое было прочитано.

С помощью этой команды для всех IP-адресов, которые сообщили о том, что хост не работает, я запускаю эту команду:

sudo nmap -Pn -sS -O -v -oN $filename $name

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

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

Есть другие идеи?

1) Надеюсь, вам не нужно пассивно собирать эту информацию.

Вы можете прослушивать трафик с помощью чего-то вроде tcpdump, wirehark, ведения журнала брандмауэра и т. Д. Со временем, собирая информацию по мере того, как системы передают данные или иным образом делают свое дело.

2) Переключатели

Если у вас есть аккуратные переключатели, они могут сказать вам несколько.

3) ARP

Системы с брандмауэром могут по-прежнему отвечать на запросы ARP, поэтому вы можете заставить их проявить себя. Вам действительно нужно только знать, что IP используется, верно? Нет, если он ни на что не ответит.

Возможно, это сработает ...

# arping -I enp0s31f6 192.168.1.1
ARPING 192.168.1.1 from 192.168.1.122 enp0s31f6
Unicast reply from 192.168.1.1 [14:CC:20:D4:F7:8E]  2.143ms
Unicast reply from 192.168.1.1 [14:CC:20:D4:F7:8E]  2.011ms
Unicast reply from 192.168.1.1 [14:CC:20:D4:F7:8E]  2.006ms
Unicast reply from 192.168.1.1 [14:CC:20:D4:F7:8E]  2.090ms
^CSent 4 probes (1 broadcast(s))
Received 4 response(s)

Или больше в сочетании, используя nmap или что-то еще, чтобы попытаться установить соединение, а затем одновременно регистрировать ответ ARP с помощью wirehark и т. Д.

Напоследок, в Nmap есть режим Arp. Никогда не пробовал.

https://nmap.org/book/nping-man-arp-mode.html

4) DHCP

Если какие-либо адреса являются адресами DHCP, в аренде DHCP будет отображаться время их последнего обновления.

Если Nmap сообщает об отказе хоста, то с высокой вероятностью можно предположить, что нет хоста, использующего этот IP-адрес. Зонды, выбранные для обнаружение хоста по умолчанию будет получать ответ от подавляющего большинства сетевых систем, и это даже лучше для систем с прямым подключением (одно и то же сетевое соединение) из-за использования зондов ARP, которые являются предварительным условием для IP-связи по каналам в стиле Ethernet. То есть, если он не отвечает на запрос ARP, у него не может быть IP-адреса.

Вы говорите: «Поскольку предполагается, что хост включен, у меня нет способа проверить, что он действительно включен», но правда в том, что он, вероятно, не работает. Фактически, если все порты отфильтрованы, он почти окончательно не работает. Для всех намерений и целей, ничто не желает общаться используя этот IP-адрес, что означает "отключение".

Наконец, ваше сканирование будет намного быстрее, если вы разрешите Nmap сканировать хосты параллельно, указав несколько целевых спецификаций в командной строке или через -iL параметр входного файла вместо использования цикла оболочки для сканирования каждого по отдельности. Даже если вы используете фоновый (&) запустить параллельный nmap процессов, вы не сможете превзойти скорость собственного адаптивного параллелизма Nmap.