Я пытаюсь просканировать TCP-порт 8092 хоста, используя nmap 7.60. Когда я запускаю nmap без прав root, он говорит, что порт фильтруется, но если я попытаюсь просканировать его с помощью sudo он говорит мне, что порт действительно открыт. Также без привилегий root nmap сообщает мне, что хост не работает, но фактически отвечает на запросы ICMP.
Хост не работает:
$ nmap -vv -n -p 8092 10.88.153.90
Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-06 11:59 CET
Initiating Ping Scan at 11:59
Scanning 10.88.153.90 [2 ports]
Completed Ping Scan at 11:59, 3.00s elapsed (1 total hosts)
Nmap scan report for 10.88.153.90 [host down, received no-response]
Read data files from: /usr/bin/../share/nmap
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds
Хост включен, но TCP-порт 8092 заблокирован:
$ nmap -vv -n -p 8092 10.88.153.90 -Pn
Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-06 12:00 CET
Initiating Connect Scan at 12:00
Scanning 10.88.153.90 [1 port]
Completed Connect Scan at 12:00, 2.00s elapsed (1 total ports)
Nmap scan report for 10.88.153.90
Host is up, received user-set.
Scanned at 2019-03-06 12:00:04 CET for 2s
PORT STATE SERVICE REASON
8092/tcp filtered unknown no-response
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.04 seconds
С помощью sudo: хост включен, а порт 8092 открыт:
(что не совсем так, потому что я не могу получить какие-либо файлы через этот порт.)
$ sudo nmap -vv -n -p 8092 10.88.153.90
Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-06 12:00 CET
Initiating Ping Scan at 12:00
Scanning 10.88.153.90 [4 ports]
Completed Ping Scan at 12:00, 0.22s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 12:00
Scanning 10.88.153.90 [1 port]
Discovered open port 8092/tcp on 10.88.153.90
Completed SYN Stealth Scan at 12:00, 0.23s elapsed (1 total ports)
Nmap scan report for 10.88.153.90
Host is up, received echo-reply ttl 64 (0.00025s latency).
Scanned at 2019-03-06 12:00:13 CET for 1s
PORT STATE SERVICE REASON
8092/tcp open unknown syn-ack ttl 64
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds
Raw packets sent: 6 (240B) | Rcvd: 13 (516B)
При этом у меня стабильный пинг на этот хост:
$ ping 10.88.153.90 -c 4
PING 10.88.153.90 (10.88.153.90) 56(84) bytes of data.
64 bytes from 10.88.153.90: icmp_seq=1 ttl=64 time=0.242 ms
64 bytes from 10.88.153.90: icmp_seq=2 ttl=64 time=0.162 ms
64 bytes from 10.88.153.90: icmp_seq=3 ttl=64 time=0.169 ms
64 bytes from 10.88.153.90: icmp_seq=4 ttl=64 time=0.152 ms
--- 10.88.153.90 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 77ms
rtt min/avg/max/mdev = 0.152/0.181/0.242/0.036 ms
И сервер, с которого я выполняю эти команды, и 10.88.153.90 находятся за брандмауэром, но они должны иметь возможность видеть друг друга и все открытые порты, но, видимо, это не так. Это из 10.88.153.90:
$ netstat -tulnp | grep 8092
tcp 0 0 0.0.0.0:8092 0.0.0.0:* LISTEN 194735/nginx: maste
У меня точно такая же ситуация с портом 22, и я могу подключиться к 10.88.153.90, используя другой частный IP-адрес из другой сети, настроенной на другой порт устройства, но когда я пытаюсь подключиться к 10.88.153.90, у меня время ожидания соединения:
$ ssh -vvv root@10.88.153.90
OpenSSH_7.7p1 Ubuntu-4ubuntu0.2, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /home/ubuntu/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 10.88.153.90 is address
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.88.153.90 [10.88.153.90] port 22.
debug1: connect to address 10.88.153.90 port 22: Connection timed out
ssh: connect to host 10.88.153.90 port 22: Connection timed out
У меня вопрос: Почему хост / порт кажутся активными / открытыми, но я все еще не могу подключиться к нему?
В конце оказалось, что на этом устройстве настроено два шлюза по умолчанию, и мне нужно было удалить второй и добавить маршрутизацию в конкретную сеть, откуда исходит мой запрос.