У меня есть два сервера, .105 и .104, и я пытаюсь устранить неполадки, связанные с отсутствием маршрута к хосту, когда .105 пытается подключиться к .104 по SSH или TCP.
На .104 запущена служба на порту 16000. .105 использовался для подключения к .104 через порт 16000, но .105 пришлось перестроить, и теперь он не может подключиться к .104 через этот порт. .105 по-прежнему может пинговать .104. Оба работают под управлением CentOS 8. Порт брандмауэра 16000 по-прежнему открыт на .104. Другой сервер, .103, может подключаться к .104 через порт 16000. Все серверы находятся в одной локальной сети.
На .105:
(base) [root@web etc]# nc 192.168.0.104 16000
Ncat: No route to host.
(base) [root@web etc]# ssh 192.168.0.104
ssh: connect to host 192.168.0.104 port 22: No route to host
.105 также не может подключиться по ssh к .104 ('нет маршрута к хосту'), но может подключиться по ssh к .103. .103 может подключиться по ssh к .104. .104 может подключиться по ssh к обоим серверам. Я пробовал имя хоста и IP-адрес.
На .105:
base) [root@web etc]# nmap --reason -p 16000 192.168.0.104
Starting Nmap 7.70 ( https://nmap.org ) at 2020-01-20 23:23 UTC
Nmap scan report for 192.168.0.104
Host is up, received arp-response (0.000097s latency).
PORT STATE SERVICE REASON
16000/tcp filtered unknown admin-prohibited ttl 64
MAC Address: 00:50:56:A5:F5:47 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.51 seconds
Не уверен, где будет происходить фильтрация, так как между двумя серверами ничего нет. Оба являются виртуальными машинами на одном физическом ящике.
Я дважды и трижды проверил настройки сети и брандмауэра, но не понимаю, в чем может быть проблема. Любая помощь будет оценена по достоинству.
На .104 (сервер .105 пытается подключиться):
[root@winst ]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens192
sources:
services: cockpit dhcpv6-client http ssh
ports: 16000/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
На .103 (третий сервер только для устранения неполадок, может подключаться к .104):
[root@monitoring ]# nmap 192.168.0.104
Starting Nmap 7.70 ( https://nmap.org ) at 2020-01-20 23:53 UTC
Nmap scan report for 192.168.0.104
Host is up (0.000097s latency).
Not shown: 996 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp closed http
3306/tcp open mysql
9090/tcp open zeus-admin
MAC Address: 00:50:56:A5:F5:47 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 14.84 seconds
На .105 (проблемный сервер):
Starting Nmap 7.70 ( https://nmap.org ) at 2020-01-20 23:53 UTC
Nmap scan report for 192.168.0.104
Host is up (0.000078s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
2049/tcp open nfs
MAC Address: 00:50:56:A5:F5:47 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 5.63 seconds
Может ли это быть связано с новой зоной, которую я создал для nfs? Возможно, я добавил зону nfs незадолго до того, как мне пришлось пересобрать .105, и, возможно, не заметил, что это сломало другой доступ.
На .104:
[root@winst]# firewall-cmd --get-active-zones
nfs
sources: 192.168.0.105 192.168.0.5
public
interfaces: ens192
решение1
Похоже, что наличие отдельной зоны nfs, которая имела .105 в качестве источника, и сделало это. После того, как я удалил зону, .105 смог ssh и также подключиться к порту 16000/tcp.