Welche konkreten Änderungen müssen vorgenommen werden, damit eine CentOS 7-Installation unter lokaler IP auf eine andere CentOS 7-Installation unter einer anderen lokalen IP zugreifen 192.168.1.6kann ?telnet192.168.1.5
Wie Sie sehen, 192.168.1.6kann 192.168.1.5wie folgt gepingt werden:
[root@localhost /]# ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.515 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.565 ms
^C
--- 192.168.1.5 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.515/0.540/0.565/0.025 ms
Aber telnetFROM 192.168.1.6TO 192.168.1.5schlägt wie folgt fehl:
[root@localhost /]# telnet 192.168.1.5
Trying 192.168.1.5...
telnet: connect to address 192.168.1.5: No route to host
Und telnetFROM 192.168.1.6TO schlägt auch port 5432wie 192.168.1.5folgt fehl:
[root@localhost /]# telnet 192.168.1.5:5432
telnet: 192.168.1.5:5432: Name or service not known
192.168.1.5:5432: Unknown host
[root@localhost /]#
PostgreSQL läuft unter 192.168.1.5und sollte empfangen telnet 192.168.1.5:5432. Daher habe ich VOR pg_hba.confdem Ausführen des obigen Befehls die folgende Zeile hinzugefügt:
host all all 192.168.1.6/24 trust
Und ich habe PostgreSQL neu gestartet, bevor ich das Obige ausgeführt pingund telneteingegeben habe systemctl restart postgresql.
Ebenso habe ich vor dem Ausführen der oben genannten pingBefehle telnetauch die folgenden Firewall-Regeln für erstellt 192.168.1.5:
[root@localhost ~]# firewall-cmd --zone=public --add-port=5432/tcp
[root@localhost ~]# firewall-cmd --permanent --zone=trusted --add-source=192.168.1.6/32
[root@localhost ~]# firewall-cmd --reload
port 5432Außerdem habe ich mit dem folgenden, in das Terminal eingegebenen Befehl bestätigt, dass PostgreSQL ausgeführt wird 192.168.1.5:
[root@localhost ~]# ss -l -n | grep 5432
u_str LISTEN 0 128 /var/run/postgresql/.s.PGSQL.5432 71466 * 0
u_str LISTEN 0 128 /tmp/.s.PGSQL.5432 71468 * 0
tcp LISTEN 0 128 127.0.0.1:5432 *:*
tcp LISTEN 0 128 ::1:5432 :::*
[root@localhost ~]#
@roaimas Vorschläge:
Gemäß dem Vorschlag von @roaima habe ich Folgendes versucht, kann aber immer noch keine Verbindung herstellen:
Von 192.168.1.6 habe ich gesendet:
[root@localhost ~]# telnet 192.168.1.5 5432
Trying 192.168.1.5...
telnet: connect to address 192.168.1.5: No route to host
Und auf 192.168.1.5 lautete die tcpdumpAntwort des Empfängers der telnetAnfrage:
[root@localhost ~]# tcpdump -i eth0 port 5432 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:52:49.309526 IP 192.168.1.6.53328 > localhost.localdomain.postgres: Flags [S], seq 3210933916, win 29200, options [mss 1460,sackOK,TS val 629624820 ecr 0,nop,wscale 7], length 0
16:52:54.312716 ARP, Request who-has localhost.localdomain tell 192.168.1.6, length 28
16:52:54.312750 ARP, Reply localhost.localdomain is-at 52:54:00:ef:35:18 (oui Unknown), length 28
^C
3 packets captured
4 packets received by filter
0 packets dropped by kernel
Ebenso habe ich von 192.168.1.6 das folgende Telnet nur an die IP-Ebene gesendet:
[root@localhost ~]# telnet 192.168.1.5
Trying 192.168.1.5...
telnet: connect to address 192.168.1.5: No route to host
[root@localhost ~]#
Und auf 192.168.1.5 lautete die tcpdumpAntwort des Empfängers der telnetAnfrage:
[root@localhost ~]# tcpdump -i eth0 port 5432 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
//THESE 2 LINES PRINTED BEFORE 2ND TELNET WAS RUN: 16:58:11.619638 ARP, Request who-has gateway tell localhost.localdomain, length 28
//THESE 2 LINES PRINTED BEFORE 2ND TELNET WAS RUN: 16:58:11.619940 ARP, Reply gateway is-at b8:ec:a3:11:74:6e (oui Unknown), length 46
16:58:35.555570 ARP, Request who-has 192.168.1.6 tell localhost.localdomain, length 28
16:58:35.555753 ARP, Reply 192.168.1.6 is-at 52:54:00:ab:31:40 (oui Unknown), length 28
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
[root@localhost ~]#
Vorschläge von @cutrightjm:
Am 192.168.1.5habe ich in einer Putty-Sitzung Folgendes eingegeben:
[root@localhost ~]# telnet localhost 5432
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Gleichzeitig habe ich in einer separaten Putty-Sitzung 192.168.1.5keine Ergebnisse von gesehen tcpdump, und zwar wie folgt:
[root@localhost ~]# tcpdump -i eth0 port 5432 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[root@localhost ~]#
@JeffSchallers Vorschläge:
Gemäß den Vorschlägen von @JeffSchaller habe ich die folgenden Befehle auf ausgeführt 192.168.1.6. Beachten Sie, dass dies CentOS 7 ist, das netstatdurch ersetzt wurde und das durch ssersetzt wurde : iptablesfirewalld
ss -rnhat 90 Zeilen Ausgabe erzeugt. Können Sie einen sinnvollen grepoder anderen Filter vorschlagen, um die Ausgabe auf die zulässige Menge zu reduzieren, die zu einem Beitrag hinzugefügt werden kann?
[root@localhost ~]# iptables -Ln
iptables: No chain/target/match by that name.
[root@localhost ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: dhcpv6-client ssh
ports: 8080/tcp
protocols:
masquerade: no
forward-ports:
sourceports:
icmp-blocks:
rich rules:
[root@localhost ~]#
Ich habe außerdem die folgenden Befehle ausgeführt 192.168.1.6:
[root@localhost ~]# ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.6 metric 100
[root@localhost ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:ab:31:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.6/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 133013sec preferred_lft 133013sec
inet6 fe80::5054:ff:feab:3140/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]#
Entfernen der Firewalls auf beiden Computern
Als Extremtest habe ich die Firewalls auf beiden 192.168.1.5und entfernt, 192.168.1.6indem ich auf beiden Rechnern yum remove firewalldund eingegeben habe. Anschließend habe ich beide Entfernungen wie folgt validiert:yum remove iptables
An 192.168.1.5:
[root@localhost ~]# systemctl status firewalld
Unit firewalld.service could not be found.
[root@localhost ~]# iptables -L -n
-bash: /sbin/iptables: No such file or directory
An 192.168.1.6:
[root@localhost ~]# systemctl status firewalld
Unit firewalld.service could not be found.
[root@localhost ~]# iptables -L -n
-bash: /sbin/iptables: No such file or directory
Als Nächstes habe ich Am eingegeben tcpdump -i eth0 port 5432 or arpund 192.168.1.5anschließend telnet 192.168.1.5 5432Am eingegeben 192.168.1.6.
Als Ergebnis des Telnet-Vorgangs wurde die folgende Ablehnungsmeldung ausgedruckt 192.168.1.6:
[root@localhost ~]# telnet 192.168.1.5 5432
Trying 192.168.1.5...
telnet: connect to address 192.168.1.5: Connection refused
[root@localhost ~]#
Gleichzeitig lautete der tcpdumpAusdruck 192.168.1.5des telnetAnrufs 1.6:
[root@localhost ~]# tcpdump -i eth0 port 5432 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:25:11.349238 ARP, Request who-has localhost.localdomain tell gateway, length 46
10:25:11.349261 ARP, Reply localhost.localdomain is-at 52:54:00:ef:35:18 (oui Unknown), length 28
10:25:14.391222 IP 192.168.1.6.53344 > localhost.localdomain.postgres: Flags [S], seq 3043089625, win 29200, options [mss 1460,sackOK,TS val 692769902 ecr 0,nop,wscale 7], length 0
10:25:14.391265 IP localhost.localdomain.postgres > 192.168.1.6.53344: Flags [R.], seq 0, ack 3043089626, win 0, length 0
10:25:19.395578 ARP, Request who-has 192.168.1.6 tell localhost.localdomain, length 28
10:25:19.396039 ARP, Reply 192.168.1.6 is-at 52:54:00:ab:31:40 (oui Unknown), length 28
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
[root@localhost ~]#
Um festzustellen, ob PostgreSQL auf lauscht port 5432, habe ich die folgenden beiden Befehle auf eingegeben 192.168.1.5:
Beachten Sie, dassfirewalldund iptableswerden beide noch entfernt, während die folgenden Befehle ausgeführt werden:
Zuerst habe ich mir die pg_hba.confDatei angesehen, 192.168.1.5um zu sehen, ob es eine Vertrauensregel gibt 192.168.1.6:
[root@localhost ~]# vi /var/lib/pgsql/data/pg_hba.conf
# LOTS OF # COMMENTED LINES OMITTED HERE FOR BREVITY
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
host all all 192.168.1.6/24 trust
# IPv6 local connections:
host all all ::1/128 trust
Als nächstes habe ich den folgenden netstatBefehl eingegeben 192.168.1.5, um zu sehen, ob es eine Regel für gibt port 5432:
[root@localhost ~]# netstat -anpt | grep LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 943/sshd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 25166/postgres
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1483/master
tcp6 0 0 127.0.0.1:45228 :::* LISTEN 19089/java
tcp6 0 0 127.0.0.1:8020 :::* LISTEN 14338/java
tcp6 0 0 :::7990 :::* LISTEN 19089/java
tcp6 0 0 :::22 :::* LISTEN 943/sshd
tcp6 0 0 ::1:5432 :::* LISTEN 25166/postgres
tcp6 0 0 127.0.0.1:7992 :::* LISTEN 19066/java
tcp6 0 0 ::1:7992 :::* LISTEN 19066/java
tcp6 0 0 ::1:25 :::* LISTEN 1483/master
tcp6 0 0 127.0.0.1:36122 :::* LISTEN 19089/java
tcp6 0 0 :::8095 :::* LISTEN 14338/java
tcp6 0 0 :::5701 :::* LISTEN 19089/java
[root@localhost ~]#
Antwort1
telnetDas erste Problem war, dass Sie die falsche Syntax für den Befehl verwendet haben . Wenn Sie den Befehl ausführen man telnet, sehen Sie, dass die Syntax ungefähr so lautet:
telnet <host> [<port>]
In Ihrem Fall sollten Sie also Folgendes ausführen:
telnet 192.168.1.5 5432
Ein zweites Problem besteht darin, dass Sie auf jedem Host eine Firewall-Regel haben, die verhindert, dassausgehendVerkehr an 5432/tcp. (Und wahrscheinlich auch an andere Ports.) Die Fehlermeldung „Keine Route zum Host“ wird durch eine iptables --j REJECTRegel in der OUTPUTKette generiert, die --reject-with icmp-host-prohibited. Hier ist ein Beispiel für die Erstellung einer solchen Regel:
iptables -I OUTPUT -p tcp --dport 5432 -j REJECT --reject-with icmp-host-prohibited
Dies erfüllt die Situation, in der die Route eindeutig existiert, weil pingsie erfolgreich ist, Ihre telnetSitzung jedoch fehlschlägt. Sie können dies selbst mit dem Befehl überprüfen iptables --line-numbers -nvL(nicht iptables -Ln, der versucht, die Regeln für die Kette aufzulisten n).
Zwei temporäre Lösungen, um zu bestätigen, dass der Verkehr tatsächlich hergestellt werden kann, sind
- Deaktivieren Sie die Firewall auf beiden Systemen vollständig
Führen Sie diese beiden Befehle auf beiden Systemen aus (Sie können sie anschließend löschen, indem Sie sie
-Idurch ersetzen-D)iptables -I INPUT -p tcp --src 192.168.1.5/30 -j ACCEPT iptables -I OUTPUT -p tcp --dst 192.168.1.5/30 -j ACCEPT
Ich bin (noch) nicht ausreichend mit dem CentOS 7-Firewall-Tool vertraut, um Ihnen eine vollständige Lösung dafür zu bieten. Ich kann mich damit befassen, oder vielleicht möchte jemand anderes diese Antwort bearbeiten, um diese Informationen bereitzustellen.