A varredura de ping do Nmap através de um túnel VPN retorna todos os hosts vivos?

4

Estou curioso para saber por que executar um nmap -sP (ping scan) em uma sub-rede remota vinculada através de um túnel IPSec site-to-site da Cisco retorna status "host up" para cada IP no intervalo.

[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

No entanto, um ping de um IP conhecido simplesmente expira ou não retorna nada ...

[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

Existe uma maneira mais eficaz de verificar dispositivos ativos conectados dessa maneira?

    
por ewwhite 22.11.2012 / 21:18

1 resposta

2

Provavelmente um TCP RST. Um trecho do manual do nmap (v 5.00):

The -sP option sends an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default. When executed by an unprivileged user, only SYN packets are sent (using a connect call) to ports 80 and 443 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified. The -sP option can be combined with any of the discovery probe types (the -P* options, excluding -PN) for greater flexibility. If any of those probe type and port number options are used, the default probes are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.

Como mostrado aqui:

# 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

No meu caso, eu tenho um par de Cisco ASAs localmente e executo o Linux e o strongswan no lado remoto. É provável que o lado remoto desde o rtt ao longo do túnel é de aproximadamente 7-9ms em média. Eu vejo que o outro lado envia arp who-has, mas isso é o máximo que eu recebo sem descriptografar os pacotes ipsec peers remotos.

    
por 22.11.2012 / 21:34