Não é possível telnet para IP privado ou para porta

Question

Quais alterações específicas precisam ser feitas para que uma instalação do CentOS 7 no IP local 192.168.1.6 possa telnet para outra instalação do CentOS 7 em outro IP local 192.168.1.5 ?

Como você pode ver, 192.168.1.6 PODE PING 192.168.1.5 da 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 telnet FROM 192.168.1.6 TO 192.168.1.5 falha 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 telnet FROM 192.168.1.6 TO port 5432 at 192.168.1.5 també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 em 192.168.1.5 e deve receber telnet 192.168.1.5:5432 . Portanto, adicionei a seguinte linha a pg_hba.conf ANTES de executar o acima:

host    all    all    192.168.1.6/24    trust

Eu reiniciei o PostgreSQL antes de executar o ping e telnet acima, digitando systemctl restart postgresql .

Da mesma forma, antes de executar os comandos acima ping e telnet , també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á sendo executado em port 5432 com 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 do @ roaima:

Por sugestão do @ roaima, tentei o seguinte, mas ainda não consegui me 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 tcpdump do final de recebimento da solicitação telnet foi:

[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 para o nível de IP apenas:

[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 tcpdump do final de recebimento da solicitação telnet foi:

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

Por sugestões do @ JeffSchaller, executei os seguintes comandos em 192.168.1.6 . Observe que este é o CentOS 7, que substituiu netstat por ss e que substituiu iptables por firewalld :

ss -rn produziu 90 linhas de saída. Você pode sugerir um grep significativo ou outro filtro para reduzir a saída ao valor permitido para adicionar a um lançamento?

[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 ~]#

Eu 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 ~]#

Remover firewalls em ambas as máquinas

Como teste extremo, removi os firewalls em 192.168.1.5 e 192.168.1.6 digitando yum remove firewalld e yum remove iptables em ambas as máquinas. Em seguida, validei as duas remoções da seguinte forma:

Em 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

Em 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

Em seguida, digitei tcpdump -i eth0 port 5432 or arp on 192.168.1.5 , seguido da digitação de telnet 192.168.1.5 5432 on 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 impressão tcpdump em 192.168.1.5 da chamada telnet de 1.6 foi:

[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á ou não ouvindo em port 5432 , digitei os dois comandos a seguir em 192.168.1.5 :

Observe que firewalld e iptables ainda são removidos enquanto os seguintes comandos são executados :

Primeiro, vi o arquivo pg_hba.conf em 192.168.1.5 para ver que existe uma regra para confiar em 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 comando netstat em 192.168.1.5 para ver se há 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 ~]#

    

Answer 1

O primeiro problema foi que você estava usando a sintaxe errada para o comando telnet . A execução de man telnet mostrará a você que a sintaxe é algo assim:

telnet <host> [<port>]

Então, no seu caso, você deve executar isso:

telnet 192.168.1.5 5432

Um segundo problema é que você tem uma regra de firewall em cada host que impede o tráfego de saída para 5432 / tcp. (E provavelmente outras portas também.) A mensagem de erro "Nenhuma rota para hospedar" é gerada por uma regra iptables --j REJECT na cadeia OUTPUT que tem --reject-with icmp-host-prohibited . Aqui está um exemplo de como criar uma 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-sucedido, mas onde a sessão telnet falha. Você mesmo pode verificar isso com o comando iptables --line-numbers -nvL (não iptables -Ln , que tenta listar as regras para a cadeia n ).

Duas correções temporárias para confirmar que o tráfego realmente pode ser estabelecido são

• Desative totalmente o firewall nos dois sistemas

• Execute esses dois comandos nos dois sistemas (você pode excluí-los depois, substituindo -I por -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 essa resposta para fornecer essa informação.