Que mudanças específicas precisam ser feitas para que uma instalação do CentOS 7 em IP local 192.168.1.6possa telnetser usada em outra instalação do CentOS 7 em outro IP local 192.168.1.5?
Como você pode ver, 192.168.1.6É CAPAZ DE PING 192.168.1.5da seguinte forma:
[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
Mas telnetFROM 192.168.1.6TO 192.168.1.5falha da seguinte forma:
[root@localhost /]# telnet 192.168.1.5
Trying 192.168.1.5...
telnet: connect to address 192.168.1.5: No route to host
E telnetFROM 192.168.1.6TO port 5432at 192.168.1.5também falha da seguinte forma:
[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 /]#
O PostgreSQL está sendo executado 192.168.1.5e deve estar recebendo telnet 192.168.1.5:5432. Portanto, adicionei a seguinte linha pg_hba.confANTES de executar o procedimento acima:
host all all 192.168.1.6/24 trust
E reiniciei o PostgreSQL antes de executar o procedimento acima pinge telnetdigitando systemctl restart postgresql.
Da mesma forma, antes de executar os comandos acima ping, telnettambém criei as seguintes regras de firewall em 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
Além disso, confirmei que o PostgreSQL está rodando port 5432com o seguinte comando digitado no terminal de 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 ~]#
Sugestões de @roaima:
Por sugestão de @roaima, tentei o seguinte, mas ainda não consigo conectar:
De 192.168.1.6, enviei:
[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
E em 192.168.1.5, o tcpdumpfinal do recebimento da telnetsolicitação era:
[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
Da mesma forma, de 192.168.1.6 enviei o seguinte telnet apenas para o nível IP:
[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 ~]#
E em 192.168.1.5, o tcpdumpfinal do recebimento da telnetsolicitação era:
[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 ~]#
Sugestões de @cutrightjm:
Em 192.168.1.5, digitei o seguinte em uma sessão do Putty:
[root@localhost ~]# telnet localhost 5432
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Simultaneamente, em uma sessão separada do Putty para 192.168.1.5, não vi resultados do tcpdump, como segue:
[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 ~]#
Sugestões de @JeffSchaller:
Seguindo as sugestões de @JeffSchaller, executei os seguintes comandos no 192.168.1.6. Observe que este é o CentOS 7, que foi substituído netstatpor sse que foi substituído iptablespor firewalld:
ss -rnproduziu 90 linhas de saída. Você pode sugerir um grepfiltro significativo ou outro para reduzir a saída ao valor permitido para adicionar a uma postagem?
[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 ~]#
Também executei os seguintes comandos em 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 ~]#
Removendo firewalls em ambas as máquinas
Como teste extremo, removi os firewalls em ambos 192.168.1.5e 192.168.1.6digitando yum remove firewallde yum remove iptablesem ambas as máquinas. Em seguida, validei ambas as remoções da seguinte forma:
Sobre 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
Sobre 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
tcpdump -i eth0 port 5432 or arpEm seguida, digitei 192.168.1.5, seguido de telnet 192.168.1.5 5432digitação 192.168.1.6.
O resultado do telnet foi a seguinte mensagem de recusa impressa em 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 ~]#
Simultaneamente, a tcpdumpimpressão 192.168.1.5da telnetligação 1.6foi:
[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 ~]#
Para determinar se o PostgreSQL está escutando ou não port 5432, digitei os dois comandos a seguir 192.168.1.5:
Observe quefirewallde iptablesambos ainda são removidos enquanto os seguintes comandos são executados:
Primeiro, visualizei o pg_hba.confarquivo 192.168.1.5para ver se existe uma regra para confiar 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
Em seguida, digitei o seguinte netstatcomando 192.168.1.5para ver se existe uma regra para 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 ~]#
Responder1
O primeiro problema foi que você estava usando a sintaxe errada para o telnetcomando. A execução man telnetmostrará que a sintaxe é mais ou menos assim:
telnet <host> [<port>]
Então, no seu caso, você deve executar isto:
telnet 192.168.1.5 5432
Um segundo problema é que você tem uma regra de firewall em cada host impedindosaídatráfego para 5432/tcp. (E provavelmente outras portas também.) A mensagem de erro "No route to host" é gerada por uma iptables --j REJECTregra na OUTPUTcadeia que possui --reject-with icmp-host-prohibited. Aqui está um exemplo de criação de tal regra:
iptables -I OUTPUT -p tcp --dport 5432 -j REJECT --reject-with icmp-host-prohibited
Isso satisfaz a situação em que a rota existe claramente porque pingé bem-sucedida, mas onde sua telnetsessão falha. Você mesmo pode verificar isso com o comando iptables --line-numbers -nvL(not iptables -Ln, que tenta listar as regras da cadeia n).
Duas soluções temporárias para confirmar que o tráfego realmente pode ser estabelecido são
- Desative totalmente o firewall em ambos os sistemas
Execute esses dois comandos em ambos os sistemas (você pode excluí-los posteriormente substituindo
-Ipor-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
(Ainda) não estou suficientemente familiarizado com a ferramenta de firewall do CentOS 7 para fornecer uma solução completa para isso. Posso cavar ou talvez alguém queira editar esta resposta para fornecer essas informações.