Pasé un día buscando cómo reenviar un puerto desde mi enrutador a mi PC, sin éxito. Y ahora me he quedado sin pistas... y estoy frustrado. He visto muchas páginas con descripciones y posibles soluciones pero de alguna manera no veo la respuesta correcta. Entonces, disculpe si esta es una pregunta que se repite, yo no lo veo así.
Esto es lo que intento hacer: quiero tener acceso a mi PC en casa cuando estoy en el trabajo. Para esto utilizo un servicio ddns.
Algunos escenarios que funcionan y otros que no: esta es mi configuración "estándar".
Tengo dos PC, una de escritorio y una portátil. En ambos tengo un servidor SSH (bitvise) y un cliente SSH (PuTTY). La computadora de escritorio ejecuta Windows 10 y la computadora portátil ejecuta Windows 7. Puedo establecer una conexión SSH desde la computadora de escritorio a la computadora portátil y al revés, sugiriendo Para mí, el puerto 22 está abierto en ambas computadoras. ¿Bien?
ISP
|
ZyXEL VMG8324-B10A (forward port 22 to 192.168.1.105)
| .1 (192.168.1.x)
|
+- .105 PC (desktop, W10, SSH server on port 22)
|
+- .107 PC (laptop, W7, SSH server on port 22)
El servicio de ddns me permite conectarme a mi red doméstica. Si intento conectarme al puerto 80, aparece la pantalla de inicio de sesión de mi enrutador, no hay problemas. Incluso lo probé con un segundo enrutador configurado para el puerto 8080 y el servidor original reenviando el puerto 8080 a este segundo servidor. Ningún problema.
Así es como se ve esa configuración.
ISP
|
ZyXEL VMG8324-B10A (forward port 8080 to 192.168.1.2)
| .1 (192.168.1.x)
|
| .2
LinkSys E3000 (configuration available on port 8080)
| .1 (10.233.1.x)
Logré conectarme con éxito a la configuración de LinkSys (en el puerto 8080) a través del proveedor de ddns. No hay problemas ahí. ¿Bien?
Como dije antes, puedo establecer una conexión entre el cliente SSH 192.168.1.105 y el servidor SSH 192.168.1.107 y también el cliente SSH 192.168.1.107 y el servidor SSH 192.168.1.105.
Pero no puedo conectarme a través de ddns a ningún servidor SSH.
Ahora puedo ver la página de configuración (puerto 80) para ZyXEL y LinkSys E3000 (el puerto de reenvío 8080 funciona). ¿Por qué no funciona para el puerto 22?
Aquí están las reglas en ZyXEL para el reenvío:
# Status Name WAN WAN_IP ServerIP TriggerStart End TranslationStart End Protocol
1 active SSH wan - 192.168.1.105 22 22 22 22 TCP/UDP
2 active http8080 wan - 192.168.1.105 8080 8080 8080 8080 TCP/UDP
Nada extraño aquí. Y es posible la comunicación SSH entre PC y portátil, no hay nada extraño en eso. ¿Dónde tengo que buscar la comunicación del ddns al PC? ¿Qué me olvido?
¡Cualquier sugerencia es bienvenida!
Editar: 5 de septiembre de 2016.
¡Problema resuelto! Con la ayuda de las respuestas a continuación, pude solucionar algunos problemas de configuración y hace unos minutos pude conectar un RDC desde mi Android a mi PC. ¡Lindo!
Respuesta1
Escribiste que estás dentro de la red y sucede lo siguiente:
El servicio de ddns me permite conectarme a mi red doméstica. Si intento conectarme al puerto 80, aparece la pantalla de inicio de sesión de mi enrutador.
Eso significa que su enrutador no admite loopback NAT. Para probar correctamente el reenvío de puertos, debe estar fuera de la red local. Podrías utilizar tu teléfono con banda ancha móvil para realizar pruebas, por ejemplo.
El ping se filtra de forma predeterminada en la mayoría de los enrutadores de consumo. Eso es seguridad a través de la oscuridad, por supuesto. También dificulta innecesariamente el diagnóstico de problemas, por lo que puede desactivar esa opción.
Además:
el software interno de su enrutador tampoco se comporta correctamente. La interfaz web se abre cuando navega hasta su dirección IP externa. ¡Esto es muy peligroso! Sin conocer la estructura de su red interna, un atacante puede obtener el control de su enrutador mediante secuencias de comandos entre sitios o similares.
Respuesta2
"Puedo establecer una conexión SSH desde la computadora de escritorio a la computadora portátil y al revés, lo que me sugiere que el puerto 22 está abierto en ambas computadoras. ¿Verdad?"
Sí. Esto indica que el servidor SSH se está ejecutando y que ningún firewall basado en software (en ninguna de las máquinas) está bloqueando ese tráfico.
Tenga en cuenta que esto no significa que pueda conectarse mediante SSH desde otra red. El Firewall de Windows puede aplicar diferentes reglas dependiendo de si una red parece ser "Privada", "Pública" o "Invitada". Entonces, sólo porque el software firewall permita una conexión no significa que otra conexión funcionará. No estoy sugiriendo que esta sea la fuente de su problema, pero si lo es, puede ser muy difícil de detectar si no piensa en ello.
Permítame también asegurarme de que comprende qué es un "puerto abierto". Nos referimos a los números de puerto TCP y a los números de puerto UDP. Estos "puertos" son simplemente números. Cuando un "puerto" está abierto, significa que se puede establecer una conexión a ese puerto.
Entonces, cuando alguien intenta enviar una solicitud SSH a la dirección IP de su hogar, su ISP diligentemente pasará ese tráfico al enrutador de su edificio. Si el resultado es una conexión exitosa, entonces el puerto está abierto.
Ahora, hay dos formas en que el enrutador puede manejar ese tráfico de manera que el puerto esté abierto.
Una de esas formas es que el enrutador ejecute un programa que responda a ese puerto. Entonces, para el puerto 22, eso normalmente significaría que el enrutador estaría ejecutando un servidor SSH. (Y, para el puerto 80, eso normalmente significaría que el enrutador está ejecutando un servidor HTTP, que a menudo llamamos "servidor web").
El otro enfoque posible es que el enrutador pase el tráfico a otro dispositivo. Normalmente, esto se hace enviando tráfico a un dispositivo en otra subred. Cuando el dispositivo hace esto, "enruta" el tráfico. Por eso a menudo llamamos a estas cosas "enrutador".
Para que el segundo enfoque funcione, el enrutador necesita saber a qué sistema enviar el tráfico. Esto se puede hacer mediante un proceso llamado "reenvío de puertos". Todo lo que realmente implica el "reenvío de puertos" es decirle al enrutador a qué número de puerto se espera que llegue el tráfico y luego a qué sistema se dirige el tráfico.
Ahora, si verifica la configuración de su enrutador, es posible que encuentre que la sección "reenvío de puertos" está en blanco. Entonces, ¿cómo se puede enrutar SSH en ese caso? Bueno, muchos enrutadores tienen una sección de configuración llamada "zona desmilitarizada", muy a menudo abreviada como "DMZ". La forma en que funciona esta DMZ es en realidad una regla bastante especial para el reenvío de puertos. Usted termina especificando qué computadora usará el enrutador, y el enrutador enviará todos los puertos a esa computadora, a menos que haya una regla más específica especificada en la sección "reenvío de puertos". Creo que la mayoría de los enrutadores no suelen colocar la DMZ en la sección de reenvío de puertos, tal vez porque la configuración de la DMZ puede hacer que el enrutador reenvíe tráfico IP además de esos puertos.
En general, sólo se puede hacer una cosa con el tráfico entrante en el puerto 22. Bien, supongo que es posible hacer más de una cosa, como hacer que el tráfico de una oficina en Seattle vaya a una computadora portátil mientras el tráfico de Tokio va a el escritorio. Sin embargo, configuraciones tan complicadas no son comunes. Lo que sería mucho más común es simplemente hacer que el reenvío de puertos envíe un puerto diferente (por ejemplo, tal vez 2222) a su otra máquina y hacer que esa máquina escuche en un puerto no estándar.
(O haga que el enrutador haga alguna traducción, de modo que el tráfico entrante en el puerto 2222 sea redirigido al puerto estándar 22 de la otra máquina. Pero entonces la máquina que recibe el tráfico ni siquiera tiene que saber que se utilizó el puerto 2222. Ocultar dicha información puede hacer que los registros sean menos útiles, y entonces necesitaría recordar que el enrutador está haciendo dicha traducción. En lugar de simplemente escuchar el puerto 2222, las cosas suelen ser más claras).
Tenga en cuenta que ICMP (utilizado por ping y múltiples implementaciones de traceroute) no utiliza un puerto TCP ni un puerto UDP. (ICMP se encuentra por encima de IP. Sin embargo, aunque IP utiliza la "Capa 3" del modelo de red OSI, ICMP realmente no califica como un protocolo que se encuentra en la "Capa 4" del modelo OSI, porque no proporciona la característica típica de seguimiento de conversaciones que tiende a distinguir un protocolo de "Capa 4").
Ahora verá que tener el puerto 22 abierto en el enrutador no necesariamente ayudará a que ambas máquinas obtengan tráfico SSH.
Comprenda que su ZyXEL probablemente tenga dos direcciones IPv4 (suponiendo que su Internet utilice IPv4). Uno es el 192.168.1.1. Es seguro informarnos de esa dirección, porque es una dirección que figura enRFC 1918. La otra es una dirección pública. Parece que la dirección cambia (ya que usa DynDNS). No nos digas esa dirección. (Para conversar, puede fingir que comienza con "203.0.113.", que en realidad es un conjunto de direcciones reservadas para ejemplos/documentación, como lo indicaRFC 5735 página 5.)
Es posible que le resulte más fácil simplemente no utilizar DNS dinámico, sino obtener una IP estática de su ISP. Conozco un ISP local donde estoy (en los EE. UU.) que puede proporcionar una IP estática (a un cliente) previa solicitud, de forma gratuita. Es posible que quieran cobrarle (y, si es así, es posible que también desee preguntar cuál es el precio de un /29, que es un bloque de 8, de los cuales 5 normalmente son utilizables por el cliente). Esto no quiere decir que su ruta de DNS dinámico no pueda funcionar, pero simplemente descarto otra opción para considerar.
El servicio de ddns me permite conectarme a mi red doméstica. Si intento conectarme al puerto 80, aparece la pantalla de inicio de sesión de mi enrutador, no hay problemas.
No dijiste qué dirección IP usas cuando te conectas al puerto 80. Pero como dijiste eso justo después de hablar sobre el uso de DDNS, parece que estás hablando de usar tu dirección IP pública. Si ese es realmente el caso, el último párrafo deLa respuesta de Daniel B.Es una advertencia bastante válida. Los enrutadores de consumo son conocidos por no tener suficiente seguridad para sus interfaces web, así que busque la opción que especifica que su interfaz web debe ser accesible únicamente mediante la conexión LAN por cable. (No confíes en las conexiones de Internet ni en Wi-Fi).