Ich habe zwei Server, .105 und .104, und versuche, das Problem „Keine Route zum Host“ zu beheben, wenn .105 versucht, über SSH oder TCP eine Verbindung zu .104 herzustellen.
.104 hat einen Dienst, der auf Port 16000 läuft. .105 stellte früher eine Verbindung zu .104 über Port 16000 her, aber .105 musste neu aufgebaut werden und kann jetzt über diesen Port keine Verbindung zu .104 herstellen. .105 kann .104 immer noch anpingen. Beide laufen unter CentOS 8. Der Firewall-Port 16000 ist auf .104 immer noch offen. Ein anderer Server, .103, kann über Port 16000 eine Verbindung zu .104 herstellen. Alle Server befinden sich im selben LAN.
Zu .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 kann auch kein SSH zu .104 ('keine Route zum Host'), aber SSH zu .103. .103 kann SSH zu .104. .104 kann SSH zu beiden Servern. Ich habe Hostname und IP-Adresse ausprobiert.
Zu .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
Ich bin nicht sicher, wo die Filterung erfolgen würde, da sich zwischen den beiden Servern nichts befindet. Beide sind VMs auf derselben physischen Box.
Ich habe die Netzwerk- und Firewall-Konfigurationen doppelt und dreifach überprüft, weiß aber nicht, wo das Problem liegen könnte. Für jede Hilfe wäre ich dankbar.
Auf .104 (Server .105 versucht, eine Verbindung herzustellen):
[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:
Auf .103 (dritter Server nur zur Fehlerbehebung, kann Verbindung zu .104 herstellen):
[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
Unter .105 (dem Problemserver):
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
Könnte es etwas mit einer neuen Zone zu tun haben, die ich für NFS erstellt habe? Möglicherweise habe ich kurz vor dem Neuaufbau von .105 eine NFS-Zone hinzugefügt und dabei nicht bemerkt, dass dadurch andere Zugriffe unterbrochen wurden.
Zu .104:
[root@winst]# firewall-cmd --get-active-zones
nfs
sources: 192.168.0.105 192.168.0.5
public
interfaces: ens192
Antwort1
Offenbar war es eine separate NFS-Zone mit .105 als Quelle. Nachdem ich die Zone gelöscht hatte, konnte .105 per SSH eine Verbindung über Port 16000/TCP herstellen.