Foro

Avatar de Lucas827171
Lucas827171
Mi vida cambió con el ADSL
25-10-2024
Resuelto

Apertura de puertos fuera del rango predeterminado

Hola a todos,

 

He creado dos servidores DHCP en mi red interna. El primero está configurado en el HGU (192.168.0.0/16) y el segundo en un router independiente que no tiene relación con Movistar, con el rango (100.100.0.0/16).

 

Quiero aclarar que el segundo router tiene configuradas reglas específicas en sus tablas de enrutamiento para redirigir el tráfico hacia el router principal, lo que permite que los dispositivos conectados a él tengan acceso a Internet. Esta parte está funcionando perfectamente.

 

Sin embargo, estoy teniendo problemas al intentar abrir puertos desde el router principal. Necesito abrir varios puertos para alojamiento web y, al especificar como IP de destino la dirección 100.100.20.4 (que corresponde a uno de mis servidores), no logro abrir los puertos.

 

He probado a realizar la configuración en ambos routers sin éxito.

¿Alguien podría ayudarme a resolver este problema o indicarme cómo hacerlo correctamente?

¡Muchas gracias de antemano!

  • Avatar de Theliel
    Theliel
    27-10-2024

    Buenas Lucas827171 

     

    Esto es lo esperable.

     

    Cuando los Router hacen uso de NAT Loopback, generalmente implementan algún "hack" o parche sucio sobre el Router para permitir esto, ya que, de forma burda, implica querer hacer uso de un Router de un modo que no es un Router. Si bien puede ser cómodo en algunos escenarios, digamos que desde un punto de vista técnico no es recomendable, a pesar de que muchos lo usamos (yo incluido)

     

    Pero eso es hablando de hacer NAT Loopback sobre el mismo Router/red, y como bien dices funciona. Pero este no es tu escenario, ya que en tu caso particular lo que tienes es un dispositivo en otra red diferente que está haciendo igualmente NAT, y esto es un problema algo mayor.

     

    Sí, cuando haces uso de NAT loopback en la primera red, el tráfico va a parar al Router y este va a ser capaz de devolverlo al destino que esté especificado en la redirección de puertos, haciendo en el proceso DNAT, es decir cambiando la dirección publica por la dirección IP de tu red local a la que se reenvía. Hasta aquí perfecto, así funciona NAT Loopback.

     

    El problema ahora es quien recoge esto. Para el otro Router, obviemos de momento el servidor proxy inverso, lo que ve es tráfico procedente de un equipo de la red principal con destino un puerto concreto del Router, ese Router a su vez estará redireccionando el tráfico al servidor Web, para ello hará de nuevo DNAT, modificando la IP destino ahora por la IP del servidor Web. Este recibe un paquete con IP de tu equipo y lo devuelve a él. El segundo Router en principio aunque depende de como esté configurado hará el proceso inverso, hará SNAT para cambiar la IP del servidor web a la suya propia, y asumiendo que esté enmascarando el tráfico será una IP Dentro de la red local principal. El problema es que en principio este lo redirigirá al equipo de la red local de arriba, y ese equipo va a rechazar el paquete, porque no ha solicitado en ningún momento tráfico desde la IP del segundo Router. Para el primero equipo, este está esperando tráfico que provenga desde la IP pública.

     

    Para poder permitir esto, el tráfico tendría que fluir del equipo al Router, El Router hacer SNAT/DNAT y enviar el tráfico al segundo Router. EL segundo Router hacer DNAT/SNAT y enviar el tráfico al servidor WEb, el servidor Web a su Router, el segundo Router deshacerlo y al Router principal, y el Router principal deshacerlo y al equipo de la red loca.

     

    Vamos, que es uno de los muchos problemas a solventar debido a estar bajo doble NAT. Esto es sencillo de realizar mediante iptables, aun cuando no podamos modificar directamente el HGU, el router propio no debería de ser problema, y sería tan sencillo como enmascarar el tráfico por ejemplo del segundo Router con la IP pública, por ejemplo, aunque esto podría traer otros problemas.

     

    En cualquier caso lo mejor para todo ello es usar simplemente un analizador de paquetes en el equipo en cuestión y otro en el servidor web, y ver como fluye el tráfico. Si se tiene un Router propio además, mejor aun, un analizador ahí para ver donde está el problema y que regla IPTables hay que intercalar.

     

    Saludos.

5 Respuestas

  • Avatar de Lucas827171
    Lucas827171
    Mi vida cambió con el ADSL
    27-10-2024

    Hola Theliel 

     

    En primer lugar, muchas gracias por tomar de tu tiempo para responder a mis preguntas. Gracias a tu explicación detallada sobre el NAT Loopback en routers, he podido aplicar las configuraciones mencionadas en tu mensaje y todo ha salido exitosamente.

     

    Agradezco mucho tu ayuda amigo.

    ¡Muchas gracias y saludos!

  • Avatar de Theliel
    Theliel
    Yo probé el VDSL
    27-10-2024

    Buenas Lucas827171 

     

    Esto es lo esperable.

     

    Cuando los Router hacen uso de NAT Loopback, generalmente implementan algún "hack" o parche sucio sobre el Router para permitir esto, ya que, de forma burda, implica querer hacer uso de un Router de un modo que no es un Router. Si bien puede ser cómodo en algunos escenarios, digamos que desde un punto de vista técnico no es recomendable, a pesar de que muchos lo usamos (yo incluido)

     

    Pero eso es hablando de hacer NAT Loopback sobre el mismo Router/red, y como bien dices funciona. Pero este no es tu escenario, ya que en tu caso particular lo que tienes es un dispositivo en otra red diferente que está haciendo igualmente NAT, y esto es un problema algo mayor.

     

    Sí, cuando haces uso de NAT loopback en la primera red, el tráfico va a parar al Router y este va a ser capaz de devolverlo al destino que esté especificado en la redirección de puertos, haciendo en el proceso DNAT, es decir cambiando la dirección publica por la dirección IP de tu red local a la que se reenvía. Hasta aquí perfecto, así funciona NAT Loopback.

     

    El problema ahora es quien recoge esto. Para el otro Router, obviemos de momento el servidor proxy inverso, lo que ve es tráfico procedente de un equipo de la red principal con destino un puerto concreto del Router, ese Router a su vez estará redireccionando el tráfico al servidor Web, para ello hará de nuevo DNAT, modificando la IP destino ahora por la IP del servidor Web. Este recibe un paquete con IP de tu equipo y lo devuelve a él. El segundo Router en principio aunque depende de como esté configurado hará el proceso inverso, hará SNAT para cambiar la IP del servidor web a la suya propia, y asumiendo que esté enmascarando el tráfico será una IP Dentro de la red local principal. El problema es que en principio este lo redirigirá al equipo de la red local de arriba, y ese equipo va a rechazar el paquete, porque no ha solicitado en ningún momento tráfico desde la IP del segundo Router. Para el primero equipo, este está esperando tráfico que provenga desde la IP pública.

     

    Para poder permitir esto, el tráfico tendría que fluir del equipo al Router, El Router hacer SNAT/DNAT y enviar el tráfico al segundo Router. EL segundo Router hacer DNAT/SNAT y enviar el tráfico al servidor WEb, el servidor Web a su Router, el segundo Router deshacerlo y al Router principal, y el Router principal deshacerlo y al equipo de la red loca.

     

    Vamos, que es uno de los muchos problemas a solventar debido a estar bajo doble NAT. Esto es sencillo de realizar mediante iptables, aun cuando no podamos modificar directamente el HGU, el router propio no debería de ser problema, y sería tan sencillo como enmascarar el tráfico por ejemplo del segundo Router con la IP pública, por ejemplo, aunque esto podría traer otros problemas.

     

    En cualquier caso lo mejor para todo ello es usar simplemente un analizador de paquetes en el equipo en cuestión y otro en el servidor web, y ver como fluye el tráfico. Si se tiene un Router propio además, mejor aun, un analizador ahí para ver donde está el problema y que regla IPTables hay que intercalar.

     

    Saludos.

  • Avatar de Lucas827171
    Lucas827171
    Mi vida cambió con el ADSL
    26-10-2024

    Buenas Theliel 

     

    Pude arreglar este problema habilitando un reverse proxy (o proxy inverso) usando un servidor con 2 tarjetas de red, una conectada por la interfaz enp1s0 al HGU y otra mediante la interfaz enp2s0 al segundo router.

     

    El problema que tengo ahora es con el NAT Loopback, este es imposible habilitarlo para el rango 100.100.0.0/16, aún habiendo definido las rutas para que el HGU sepa dónde redirigir el tráfico.

     

    Muchas gracias por su respuesta.

  • Avatar de Theliel
    Theliel
    Yo probé el VDSL
    26-10-2024

    Buenas Lucas827171 

     

    Pues imagino que es un problema doble.

     

    Por un lado, sería necesario configurar rutas en el HGU, obligado, o como sabría este sino hacia donde enviar el tráfico de una IP que no pertenece a él.

     

    Por otro lado, habría que asumir que el HGU (que no deja de ser un Router doméstico) te va a permitir por la interfaz Web realizar una redirección a una IP que no está dentro de su rango, lo cual dudo que permita por una cuestión de evitar problemas a los usuarios. ¿Pero que problemas podría tener permitir esto? Pues muy fácil, que un usuario doméstico ya de por sí le cuesta enormemente saber que es una redirección de puertos y que IP poner. Con esta restricción le dice al usuario que meta la IP correctamente si se está equivocando de red, dado que el 99.99% de los usuarios no usa dos redes en sus casas, y para la mayoría que requiere de funcionalidades avanzadas suele instalar su propio Router.

     

    Así que si el HGU no permite este tipo de redirecciones... se podría intentar forzar la petición HTTP para saltarse el error si es una comprobación interna rutinaria por JavaScript, o intentarlo por SSH. Pero ninguna de las dos tiene garantías en caso de que se esté imponiendo dicha limitación.

     

    Saludos.

  • Avatar de Técnico-Movistar
    Técnico-Movistar
    Responsable Técnico
    25-10-2024

    Hola Lucas827171 

     

    Bienvenid@ a la Comunidad Movistar.

     

    Confirmarte que al tratarse de un configuración sobre apertura de puertos para el alojamiento web y la especificación de la dirección IP de destino, no tenemos información al respecto de dicha configuración. En todo caso, dejamos el hilo abierto y a tú disposición para poder recibir aportaciones por parte de otros miembros de la Comunidad que a raíz de su propia experiencia, te puedan ayudar al respecto de lo que nos comentas. 

     

    Un Saludo, Jesús.