No se puede telnet a una IP privada o a un puerto

¿Qué cambios específicos se deben realizar para que una installation de CentOS 7 en la IP local 192.168.1.6 pueda hacer telnet a otra installation de CentOS 7 en otra IP local 192.168.1.5 ?

Como puede ver, 192.168.1.6 PUEDE PING 192.168.1.5 siguiente manera:

 [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 

Pero telnet DE 192.168.1.6 A 192.168.1.5 falla de la siguiente manera:

 [root@localhost /]# telnet 192.168.1.5 Trying 192.168.1.5... telnet: connect to address 192.168.1.5: No route to host 

Y telnet FROM 192.168.1.6 TO port 5432 en 192.168.1.5 también falla de la siguiente manera:

 [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 se ejecuta en 192.168.1.5 y debería recibir telnet 192.168.1.5:5432 . Por lo tanto, agregué la siguiente línea a pg_hba.conf ANTES de ejecutar lo anterior:

 host all all 192.168.1.6/24 trust 

Y reinicié PostgreSQL antes de ejecutar el ping y telnet escribiendo systemctl restart postgresql .

De manera similar, antes de ejecutar los commands ping y telnet , también creé las siguientes reglas de firewall en 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 

Además, confirmé que PostgreSQL se está ejecutando en el port 5432 con el siguiente command escrito en el 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 ~]# 


Sugerencias de @ roaima:


Sugerencia de Per @ roaima, intenté lo siguiente, pero aún no puedo conectarme:

De 192.168.1.6, envié:

 [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 

Y en 192.168.1.5, el tcpdump del extremo receptor de la request telnet fue:

 [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 captunetworking 4 packets received by filter 0 packets dropped by kernel 

Del mismo modo, desde 192.168.1.6 envié el siguiente telnet solo al nivel de 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 ~]# 

Y en 192.168.1.5, el tcpdump del extremo receptor de la request telnet fue:

 [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 captunetworking 4 packets received by filter 0 packets dropped by kernel [root@localhost ~]# 


Sugerencias de @ cutrightjm:


En 192.168.1.5 , escribí lo siguiente en una sola session de Putty:

 [root@localhost ~]# telnet localhost 5432 Trying ::1... Connected to localhost. Escape character is '^]'. 

Al mismo time, en una session de Putty separada a 192.168.1.5 , no vi ningún resultado del tcpdump , de la siguiente manera:

 [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 captunetworking 0 packets received by filter 0 packets dropped by kernel [root@localhost ~]# 


@ Sugerencias de JeffSchaller:


Las sugerencias de Per @ JeffSchaller, ejecuté los siguientes commands en 192.168.1.6 . Tenga en count que esto es CentOS 7, que ha reemplazado netstat con ss , y que ha reemplazado a iptables con firewalld :

ss -rn produjo 90 líneas de salida. ¿Puede sugerir un grep significativo u otro filter para networkingucir la producción a la cantidad permitida para agregar a una publicación?

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

También ejecuté los siguientes commands en 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 prefernetworking_lft forever inet6 ::1/128 scope host valid_lft forever prefernetworking_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 prefernetworking_lft 133013sec inet6 fe80::5054:ff:feab:3140/64 scope link valid_lft forever prefernetworking_lft forever [root@localhost ~]# 


Eliminación de cortafuegos en ambas máquinas


Como testing extrema, eliminé los firewalls tanto en 192.168.1.5 como en 192.168.1.6 escribiendo yum remove firewalld y yum remove iptables en ambas máquinas. Luego validé ambas eliminaciones de la siguiente manera:

En 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 

En 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 

A continuación, escribí tcpdump -i eth0 port 5432 or arp en 192.168.1.5 , y luego escribí telnet 192.168.1.5 5432 en 192.168.1.6 .

El resultado del telnet fue el siguiente post de rechazo impreso en 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 ~]# 

Simultáneamente, la printing de tcpdump en 192.168.1.5 de la llamada de telnet desde 1.6 fue:

 [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 captunetworking 6 packets received by filter 0 packets dropped by kernel [root@localhost ~]# 

Para determinar si PostgreSQL está o no escuchando en el port 5432 , escribí los siguientes dos commands en 192.168.1.5 :

Tenga en count que firewalld e iptables se siguen eliminando mientras se ejecutan los siguientes commands :

Primero, vi el file pg_hba.conf en 192.168.1.5 para ver que hay una regla para confiar en 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 

A continuación, escribí el siguiente command netstat en 192.168.1.5 para ver si hay una regla para el 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 ~]# 

El primer problema fue que estaba usando la syntax incorrecta para el command telnet . Correr man telnet le mostrará que la syntax es algo como esto:

 telnet <host> [<port>] 

Entonces en tu caso, deberías ejecutar esto:

 telnet 192.168.1.5 5432 

Un segundo problema es que tiene una regla de firewall en cada host que impide el tráfico saliente a 5432 / tcp. (Y probablemente también otros puertos). El post de error, "No route to host", se genera mediante una regla de iptables --j REJECT en la cadena OUTPUT que tiene --reject-with icmp-host-prohibited . Aquí hay un ejemplo de cómo crear dicha regla:

 iptables -I OUTPUT -p tcp --dport 5432 -j REJECT --reject-with icmp-host-prohibited 

Esto satisface la situación donde la ruta existe claramente porque el ping tiene éxito, pero donde falla su session de telnet . Usted mismo puede verificar esto con el command iptables --line-numbers -nvL (no iptables -Ln , que intenta listr las reglas para la cadena n ).

Dos correcciones temporales para confirmar que el tráfico realmente se puede establecer son

  • Deshabilite el firewall en ambos sistemas por completo
  • Ejecute estos dos commands en ambos sistemas (puede eliminarlos luego reemplazando -I con -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 

Todavía no estoy lo suficientemente familiarizado con la herramienta de firewall CentOS 7 para darle una solución completa. Puedo ir a excavar o tal vez alguien más quiera editar esta respuesta para proporcionar esa información.