☰

ssh/tcp sem rota para host proibido pelo administrador

tag-icon • tag-icon networking port route
ssh/tcp sem rota para host proibido pelo administrador

Tenho dois servidores, .105 e .104, e estou tentando solucionar problemas de 'sem rota para host' quando o .105 tenta se conectar ao .104 por meio de ssh ou tcp.

.104 tem um serviço em execução na porta 16000. .105 costumava se conectar a .104 por meio da porta 16000, mas .105 teve que ser reconstruído e agora não consegue se conectar a .104 por meio dessa porta. .105 ainda pode executar ping em .104. Ambos executam CentOS 8. A porta 16000 do firewall ainda está aberta em .104. Outro servidor, .103, é capaz de se conectar ao .104 através da porta 16000. Todos os servidores estão na mesma LAN.

Em 0,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 também não pode ssh para .104 ('sem rota para host'), mas pode ssh para .103. .103 pode ssh em .104. .104 pode fazer ssh em ambos os servidores. Tentei nome de host e endereço IP.

Em 0,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

Não tenho certeza de onde ocorreria a filtragem, pois não há nada entre os dois servidores. Ambos são VMs na mesma caixa física.

Verifiquei duas e três vezes as configurações de rede e firewall, mas não sei qual poderia ser o problema. Qualquer ajuda seria apreciada.

Em .104 (o servidor .105 está tentando se conectar):

[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:

Em .103 (terceiro servidor apenas para solução de problemas, pode se conectar 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

Em .105 (o servidor com problema):

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

Poderia ter algo a ver com uma nova zona que criei para nfs? Posso ter adicionado a zona nfs não muito antes de reconstruir .105 e posso não ter percebido que ela quebrou outro acesso.

Em .104:

[root@winst]# firewall-cmd --get-active-zones
nfs
  sources: 192.168.0.105 192.168.0.5
public
  interfaces: ens192

Responder1

Parece que ter uma zona nfs separada que tinha 0,105 como fonte foi o que aconteceu. Depois de excluir a zona, .105 poderia ssh e também conectar-se na porta 16000/tcp.

informação relacionada