No se puede acceder a un servidor Linux después de cambiar el ISP

Question

La organización a la que pertenece la red este servidor está cambiando su ISP. Cuando cambio este servidor a nuevos valores de IP, puerta de enlace, etc., ya no puedo conectarme a través de ssh. Fui a una de las herramientas de verificación de puertos y cuando revisé el puerto 22 me devolvió "No pude ver su servicio en _new_IP_value_ en el puerto 22".

La nueva IP es estática. No hay ningún enrutador en el servidor en cuestión, ni reenvío de puertos: el cable de red va directamente al servidor.

Naturalmente, pensé que la red de la organización o el nuevo ISP estaba bloqueando el puerto 22, así que llamé al administrador de la red y le pedí que lo abriera o le dijera al ISP que lo abriera. Él dijo que lo haría. Pero nada cambió. Lo llamé un día después con la misma pregunta, pero se notaba que estaba ocupado, dijo que hizo lo que le pedí y básicamente me colgó.

Entonces, ahora estoy pensando que, después de todo, tal vez haya algún problema con la configuración del servidor. Pero todas las herramientas de Linux, como lsof, netstat, nmap, etc., indican que sshd está funcionando y escuchando en el puerto 22, que el puerto 22 está abierto, etc. y todavía puedo ingresar mediante ssh al servidor cuando lo vuelvo a nuestro Red del antiguo ISP: todo lo que cambio es IP, puerta de enlace, DNS, nada más.

¿Podría haber algo en este servidor que esté bloqueando las conexiones ssh cuando el servidor está en la red del nuevo ISP, pero no en la anterior? El sistema operativo es Linux Mint.

Answer 1

Ejecute una captura de paquetes en el cliente y ejecute una captura de paquetes en el servidor. Las herramientas más comunes son Wireshark y tcpdump:

tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"

• Si ve que los paquetes TCP SYN salen del cliente, pero no llegan al servidor, el problema suele estar en la red, muy probablemente en el ISP del servidor, porque las herramientas de verificación de puertos en línea han descartado la posibilidad de que el ISP del lado del cliente sea el raro.

  (Tal vez el administrador no abrió los puertos en absoluto, o no los abrió para la dirección correcta. No es raro que el puerto 3389 también esté cerrado a nivel de ISP).

  Creo tcptracerouteque posiblemente pueda ayudar a descubrir hasta dónde llegan los paquetes antes de desaparecer.

• Si ve paquetes TCP SYN que llegan al servidor, pero no reciben respuestaen absoluto, el problema está en el servidor. Podría ser el firewall interno del servidor (tcpdump obtiene paquetesantesgolpean el firewall), así que verifique si tiene alguna regla de iptablesycualquier regla nft.

  También asegúrese de que el servidor tenga unruta de regresoal cliente, y que efectivamente va a la puerta de enlace correcta a través de la interfaz correcta:

  ip -4 route get <client_ip>
  ip -4 route show match <client_ip>
  

  Ejecute también systemctl cat sshdpara comprobar si hay listas blancas de direcciones IP a nivel de cgroup. Ejecute también ip xfrm policypara comprobar si hay políticas de IPsec.

• Si ve que llegan paquetes TCP SYN, pero generan respuestas TCP RST, aún podría ser el firewall o podría ser que el demonio SSH esté configurado paraescucharen la dirección equivocada. (No mencionaste lo quedirección localse muestra en lsof/netstat junto al "puerto 22". Si muestra 0.0.0.0:22 o [::]:22, eso está bien, pero si muestra la dirección anterior, debe cambiarse en sshd_config.)

• Si ve que llegan paquetes TCP SYN, las respuestas SYN/ACK salen del servidor, pero el cliente nunca recibe esas respuestas; también es un problema de red y, nuevamente, muy probablemente del lado del ISP del servidor.