Estoy alojando algunos sitios/servicios como Jenkins en un servidor que tengo en casa. Me gustaría que sean accesibles desde Internet así como desde la intranet a través de un nombre de dominio público. Para esto, registré un nombre de dominio noip que apunta a mi ipv4 público (dinámico). El enrutador tiene reenvíos de puertos configurados para NAT de un puerto en mi servidor.
Todo esto funcionaba bien, hasta que cambié de proveedor de red y, por lo tanto, de enrutador el fin de semana pasado.
Ahora no puedo conectarme a mis sitios desde la intranet usando el nombre de dominio público que se está resolviendo en mi IP pública.
Lo que he probado:
- Hacer ping al nombre de dominio público desde la intranet resuelve la IP pública correcta -> no hay problema de DNS
- Se puede acceder a los sitios desde Internet cuando se utiliza el nombre de dominio público (o IP) y el puerto correcto.
- NO se puede acceder a los sitios desde la intranet cuando se utiliza el nombre de dominio público (o IP) y el puerto correcto. En este caso el navegador muestra un error de tiempo de espera de conexión de red (ERR_CONNECTION_TIMED_OUT)
- Se puede acceder a los sitios desde la intranet cuando se utiliza la IP interna y el puerto correcto (como se especifica en la regla de reenvío de puerto para el destino)
¿Qué configuración de red en el enrutador se debe cambiar para que pueda enrutarlo correctamente desde la intranet?
Manual del enrutador:https://www.sunrise.ch/content/dam/sunrise/residential/hilfe/internet/Sunrise_Home_User_Manual_Sunrise_Internet_Box_new_firmware_e.pdf
Configuración del enrutador:
Actualmente, el firewall está deshabilitado para garantizar que no esté causando problemas:
Esta es una duplicación de mi publicación aquí:https://networkengineering.stackexchange.com/posts/59290
Respuesta1
Esta es principalmente una respuesta basada en conjeturas basada en el problema más común de este tipo. Sin embargo, para estar completamente seguro, necesitaría investigar lo que ve el servidor (Wireshark/tcpdump son buenas herramientas).
DNAT (reenvío de puertos) dentro de la misma subred es muy problemático, ya que la ruta de retorno del servidor al cliente generalmente pasa por alto el enrutador y no hay posibilidad de des-NAT de este tráfico de retorno.
Para solucionar este problema, algunos enrutadores (pero no todos) tienen una opción de "bucle invertido NAT" o "horquilla NAT". Según tengo entendido, esta opción realiza además SNAT para todas las conexiones, reescribiendo elclienteDirección IP y hacer que el servidor piense que todas las conexiones provienen del propio enrutador.
Sin bucle invertido/horquilla, sus clientes pueden llegar al servidor, pero no reconocen las respuestas que han llegado del servidor (ya que la dirección IP ya no coincide), por lo que nunca se podrá establecer una conexión.
Si su enrutador no tiene esta opción, pero tiene una configuración NAT avanzada manual, usted mismo puede crear una regla NAT similar: dígale al enrutador que "enmascare" todas las conexiones que vienen de la LAN y regresan a la misma LAN.
(Esto, por supuesto, todavía tiene la misma desventaja de ocultar las direcciones IP de los clientes del servidor).
Sin embargo, en mi humilde opinión, la mejor opción (no probada personalmente, pero no tengo motivos para creer que no debería funcionar) es colocar el servidor en unsubred diferentedel resto de tus dispositivos. Siempre que el tráfico de retorno del servidor a los clientes pase a través de la puerta de enlace, se debe evitar el problema, incluso si no hay separación de VLAN y si ambas subredes viven en la misma Ethernet.
Lo anterior también podría implementarse cambiando la máscara de subred o agregando rutas personalizadas al servidor.