¿Qué cambios específicos se deben realizar para que una instalación de CentOS 7 en una IP local 192.168.1.6pueda telnetconvertirse en otra instalación de CentOS 7 en otra IP local 192.168.1.5?
Como puede ver, 192.168.1.6PUEDE HACER PING 192.168.1.5de la 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 telnetFROM 192.168.1.6TO 192.168.1.5falla 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 telnetFROM 192.168.1.6TO port 5432también 192.168.1.5falla 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 está ejecutando en 192.168.1.5y debería estar recibiendo telnet 192.168.1.5:5432. Por lo tanto, agregué la siguiente línea pg_hba.confANTES de ejecutar lo anterior:
host all all 192.168.1.6/24 trust
Y reinicié PostgreSQL antes de ejecutar lo anterior pingy telnetescribir systemctl restart postgresql.
De manera similar, antes de ejecutar los comandos pingy anteriores 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 port 5432con el siguiente comando escrito en la 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:
Según la sugerencia de @roaima, intenté lo siguiente, pero todavía no puedo conectarme:
Desde 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 tcpdumpdestinatario de la telnetsolicitud 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 captured
4 packets received by filter
0 packets dropped by kernel
De manera similar, 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 tcpdumpdestinatario de la telnetsolicitud 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 captured
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 sesión de PuTTY:
[root@localhost ~]# telnet localhost 5432
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Simultáneamente, en una sesión separada de Putty 192.168.1.5, no vi resultados de la tcpdumpsiguiente 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 captured
0 packets received by filter
0 packets dropped by kernel
[root@localhost ~]#
Sugerencias de @JeffSchaller:
Según las sugerencias de @JeffSchaller, ejecuté los siguientes comandos en 192.168.1.6. Tenga en cuenta que este es CentOS 7, que se reemplazó netstatcon ssy que se reemplazó iptablescon firewalld:
ss -rnprodujo 90 líneas de producción. ¿Puede sugerir un grepfiltro significativo o de otro tipo para reducir 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 comandos 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 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 ~]#
Eliminación de firewalls en ambas máquinas
Como prueba extrema, eliminé los firewalls en ambas 192.168.1.5máquinas 192.168.1.6escribiendo yum remove firewalldy yum remove iptablesen 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 arpy 192.168.1.5luego telnet 192.168.1.5 5432escribí 192.168.1.6.
El resultado del telnet fue el siguiente mensaje 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 ~]#
Al mismo tiempo, la tcpdumpcopia impresa 192.168.1.5de la telnetllamada 1.6fue:
[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 si PostgreSQL está escuchando o no port 5432, escribí los dos comandos siguientes en 192.168.1.5:
Tenga en cuenta quefirewalldyiptables ambos aún se eliminan mientras se ejecutan los siguientes comandos:
Primero, vi el pg_hba.confarchivo 192.168.1.5para ver que hay una regla en la que 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
A continuación, escribí el siguiente netstatcomando 192.168.1.5para ver si hay una regla 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 ~]#
Respuesta1
El primer problema fue que estabas usando una sintaxis incorrecta para el telnetcomando. Ejecutar man telnetle mostrará que la sintaxis 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 impidesalientetráfico a 5432/tcp. (Y probablemente también a otros puertos). El mensaje de error "No hay ruta al host" lo genera una iptables --j REJECTregla en la OUTPUTcadena que tiene --reject-with icmp-host-prohibited. A continuación se muestra un ejemplo de creación de dicha regla:
iptables -I OUTPUT -p tcp --dport 5432 -j REJECT --reject-with icmp-host-prohibited
Esto satisface la situación en la que la ruta existe claramente porque pingtiene éxito, pero la telnetsesión falla. Usted mismo puede comprobar esto con el comando iptables --line-numbers -nvL(not iptables -Ln, que intenta enumerar las reglas de la cadena n).
Dos correcciones temporales para confirmar que realmente se puede establecer tráfico son
- Deshabilite el firewall en ambos sistemas por completo
Ejecute estos dos comandos en ambos sistemas (puede eliminarlos luego reemplazándolos
-Icon-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
No estoy (todavía) lo suficientemente familiarizado con la herramienta de firewall CentOS 7 para brindarle una solución completa para eso. Puedo investigar o tal vez a alguien más le gustaría editar esta respuesta para proporcionar esa información.