Мне любопытно, почему запускается nmap -sP (сканирование ping) в удаленной подсети, подключенной через туннель Cisco site-to-site IPSec, возвращает статус «хост включен» для каждого IP-адреса в диапазоне.
[root@xt ~]# nmap -sP 192.168.108.*
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2012-11-22 14:08 CST
Host 192.168.108.0 appears to be up.
Host 192.168.108.1 appears to be up.
Host 192.168.108.2 appears to be up.
Host 192.168.108.3 appears to be up.
Host 192.168.108.4 appears to be up.
Host 192.168.108.5 appears to be up.
.
.
.
Host 192.168.108.252 appears to be up.
Host 192.168.108.253 appears to be up.
Host 192.168.108.254 appears to be up.
Host 192.168.108.255 appears to be up.
Nmap finished: 256 IP addresses (256 hosts up) scanned in 14.830 seconds
Однако пинг известного IP просто истекает или ничего не возвращает ...
[root@xt ~]# ping 192.168.108.201
PING 192.168.108.201 (192.168.108.201) 56(84) bytes of data.
--- 192.168.108.201 ping statistics ---
144 packets transmitted, 0 received, 100% packet loss, time 143001ms
Есть ли более эффективный способ сканирования подключенных таким образом устройств в реальном времени?
Вероятно, TCP RST. Выдержка из руководства по Nmap (версия 5.00):
Параметр -sP отправляет эхо-запрос ICMP, TCP SYN на порт 443, TCP ACK на порт 80 и запрос отметки времени ICMP по умолчанию. Когда выполняется непривилегированным пользователем, только пакеты SYN отправляются (с использованием вызова подключения) на порты 80 и 443 на цели. Когда привилегированный пользователь пытается сканировать цели в локальной сети Ethernet, используются запросы ARP, если не указан параметр --send-ip. Параметр -sP можно комбинировать с любым типом зонда обнаружения (параметры -P *, кроме -PN) для большей гибкости. Если используются какие-либо из этих параметров типа зонда и номера порта, зонды по умолчанию отменяются. Если между исходным хостом, на котором запущен Nmap, и целевой сетью установлены строгие брандмауэры, рекомендуется использовать эти расширенные методы. В противном случае хосты могут быть пропущены, когда брандмауэр отбрасывает зонды или их ответы.
Как показано здесь:
# nmap -sP 10.99.10.19
Host 10.99.10.19 is up (0.0015s latency).
21:31:13.338418 IP (tos 0x0, ttl 51, id 28548, offset 0, flags [none], proto ICMP (1), length 28)
10.0.0.20 > 10.99.10.19: ICMP echo request, id 57832, seq 0, length 8
21:31:13.338625 IP (tos 0x0, ttl 50, id 7277, offset 0, flags [none], proto TCP (6), length 44)
10.0.0.20.63105 > 10.99.10.19.443: Flags [S], cksum 0xe71d (correct), seq 4106918263, win 3072, options [mss 1460], length 0
21:31:13.338780 IP (tos 0x0, ttl 52, id 11356, offset 0, flags [none], proto TCP (6), length 40)
10.0.0.20.63105 > 10.99.10.19.80: Flags [.], cksum 0x3276 (correct), seq 4106918263, ack 774547350, win 1024, length 0
21:31:13.339771 IP (tos 0x0, ttl 55, id 35529, offset 0, flags [none], proto ICMP (1), length 40)
10.0.0.20 > 10.99.10.19: ICMP time stamp query id 23697 seq 0, length 20
21:31:13.340590 IP (tos 0x0, ttl 255, id 63189, offset 0, flags [none], proto TCP (6), length 40)
10.99.10.19.80 > 10.0.0.20.63105: Flags [R.], cksum 0x3272 (correct), seq 1, ack 0, win 1024, length 0
В моем случае у меня есть пара Cisco ASA локально и я запускаю Linux и strongswan на удаленной стороне. Скорее всего, это удаленная сторона, поскольку в среднем RTT по туннелю составляет примерно 7-9 мс. Я вижу, что другая сторона отправляет arp who-has, но это все, что я могу сделать, не расшифровывая пакеты удаленных узлов ipsec.