Estoy en Fedora 19 y tengo un problema con ssh .
Ssh está funcionando y puedo conectarme cuando ingreso mi IP de LAN. Pero cuando pruebo el nombre de mi servidor (blahblah.no-ip.org ) Recibo una conexión rechazada. No-ip ya se está ejecutando como un servicio y está funcionando correctamente (enviando la ip correcta).
Ya configuré el reenvío de puertos en mi enrutador, también cambié el puerto de ssh tanto en el servicio como en el reenvío de puertos del enrutador (en caso de que mi querido ISP decidiera bloquear esos puertos). Pero aún recibo una conexión rechazada y cuando nmap el nombre de host veo que el puerto ssh está cerrado.
Sin embargo, una cosa:tengo dos PC con la misma IP externa (configuré el reenvío de puertos a la IP interna correcta). Cuando nmap blahblah.no-ip.org Tengo un puerto 23 y 80 abierto. 80 parece estar bien, pero nunca he iniciado el servicio telnet en mi máquina.
¿Alguna idea de qué más probar? El enrutador es zte zxv10 y el reenvío de puertos está configurado correctamente. Digo esto porque ya configuré el reenvío de puertos para diluvio y funciona correctamente.
Respuesta aceptada:
No es posible conectarse a una dirección IP pública con reenvío de puerto desde dentro de la misma LAN. Para explicar esto, necesitaré un ejemplo.
Supongamos que la IP privada de su enrutador es 192.168.1.1 con IP pública 10.1.1.1. Su servidor está en el puerto 2222 de 192.168.1.2. Configuró el reenvío de puertos de 10.1.1.1:1111 a 192.168.1.2:2222.
Si alguien en Internet (10.3.3.3) quiere hablar contigo, genera un paquete:
Source: 10.3.3.3 port 33333
Dest: 10.1.1.1 port 1111
Su enrutador recibe el paquete en 10.1.1.1 y lo reescribe:
Source: 10.3.3.3 port 33333
Dest: 192.168.1.2 port 2222
Su servidor recibe ese paquete y envía una respuesta:
Source: 192.168.1.2 port 2222
Dest: 10.3.3.3 port 33333
Su enrutador recibe ese paquete en 192.168.1.1 y lo reescribe:
Source: 10.1.1.1 port 1111
Dest: 10.3.3.3 port 33333
Y la conexión funciona, y todos están felices.
Ahora suponga que se conecta desde dentro de su LAN (192.168.1.3). Generas un paquete:
Source: 192.168.1.3 port 33333
Dest: 10.1.1.1 port 1111
Su enrutador recibe el paquete en 10.1.1.1 y lo reescribe:
Source: 192.168.1.3 port 33333
Dest: 192.168.1.2 port 2222
Su servidor recibe ese paquete y envía una respuesta:
Source: 192.168.1.2 port 2222
Dest: 192.168.1.3 port 33333
Aquí es donde encontramos un problema. Debido a que la IP de destino está en su LAN, su servidor no envía ese paquete al enrutador para que lo reescriba. En cambio, lo envía directamente a 192.168.1.3. Pero esa máquina no espera una respuesta del puerto 2222 de 192.168.1.2. Espera una del puerto 1111 de 10.1.1.1. Por lo tanto, se niega a escuchar este paquete "falso" y las cosas no funcionan.
Relacionado:¿Pausa prolongada de SSH 7.4 en "compromiso:red"?La forma en que soluciono esto es configurar mi enrutador (que también proporciona DNS para mi LAN) para devolver la dirección IP privada de mi servidor cuando busco mi nombre de host DDNS. De esa manera, cuando estoy en mi red doméstica, me conecto directamente al servidor y omito el reenvío de puertos. (Esta solución solo funciona cuando los reenvíos de puertos no cambian el número de puerto, solo la dirección IP. Y solo puede tener 1 servidor por nombre de host público).