Tengo dos servidores, .105 y .104, y estoy intentando solucionar problemas de "no hay ruta al host" cuando .105 intenta conectarse a .104 a través de ssh o tcp.
.104 tiene un servicio ejecutándose en el puerto 16000. .105 solía conectarse a .104 a través del puerto 16000, pero .105 tuvo que ser reconstruido y ahora no puede conectarse a .104 a través de ese puerto. .105 todavía puede hacer ping a .104. Ambos ejecutan CentOS 8. El puerto de firewall 16000 todavía está abierto en .104. Otro servidor, .103, puede conectarse a .104 a través del puerto 16000. Todos los servidores están en la misma LAN.
En .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 tampoco puede enviar ssh a .104 ('sin ruta al host'), pero puede enviar ssh a .103. .103 puede conectarse a .104. .104 puede enviarse por ssh a ambos servidores. Probé con el nombre de host y la dirección IP.
En .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
No estoy seguro de dónde se produciría el filtrado ya que no hay nada entre los dos servidores. Ambas son máquinas virtuales en la misma caja física.
He verificado dos y tres veces las configuraciones de red y firewall, pero no sé cuál podría ser el problema. Cualquier ayuda sería apreciada.
En .104 (el servidor .105 está intentando conectarse):
[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:
En .103 (el tercer servidor solo para solucionar problemas, puede conectarse a .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
En .105 (el servidor problemático):
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
¿Podría tener algo que ver con una nueva zona que creé para nfs? Es posible que haya agregado la zona nfs no mucho antes de tener que reconstruir .105 y es posible que no haya notado que interrumpió otros accesos.
En .104:
[root@winst]# firewall-cmd --get-active-zones
nfs
sources: 192.168.0.105 192.168.0.5
public
interfaces: ens192
Respuesta1
Parece que tener una zona nfs separada que tenía .105 para la fuente es lo que lo hizo. Una vez que eliminé la zona, .105 pudo realizar ssh y también conectarse en el puerto 16000/tcp.