¿Puedes alojar un servidor con Starlink sin una IP pública IPv4?

Una dirección privada de la red de Starlink aparece antes que la primera pública

Esta traza se hizo en octubre de 2026 desde un equipo de la red de casa. Fue la segunda de dos ejecuciones el mismo día, y el segundo salto no respondió en ninguna de las dos.

tracepath -n -m 8 1.1.1.1

La salida, transcrita con una etiqueta en lugar de cada dirección:

 1?: [LOCALHOST]                                    pmtu 1500
 1:  home router                                    1.998ms
 1:  home router                                    1.792ms
 2:  no reply
 3:  private address (RFC 1918), Starlink's side   34.218ms
 4:  public address, SpaceX (AS14593)              35.767ms (router returned corrupted payload) asymm 7
 5:  public address, SpaceX (AS14593)              36.125ms
 6:  public address, owner not checked             35.623ms asymm 7
 7:  public address, Cloudflare                    44.837ms
 8:  public address, Cloudflare                    36.379ms asymm 9
     Too many hops: pmtu 1500

Las etiquetas de la salida están en inglés: "home router" es el router de casa, "no reply" significa que no hubo respuesta, "private address" y "public address" son una dirección privada y una pública, "Starlink's side" indica el lado de Starlink y "owner not checked" indica que no se comprobó de quién es.

El salto 1 es el router de casa. El salto 2 no devolvió nada. El salto 3 es una dirección privada dentro de la red de Starlink, y la primera dirección pública es el salto 4, en la red de SpaceX.

RFC 1918 reserva bloques de direcciones privadas para usarlos dentro de una red. Esas direcciones no tienen significado global ("have no global meaning"), y las rutas hacia ellas no deben pasarse de una red a otra (sección 3, consultado en octubre de 2026). El salto 3 solo significa algo dentro de la red de Starlink. Un salto privado antes del primer salto público es el aspecto que tiene un CGNAT visto desde dentro de casa.

RFC 6598 reserva 100.64.0.0/10 como espacio de direcciones compartido ("Shared Address Space") para el NAT de nivel de operador, y espera que los proveedores numeren con ese bloque los enlaces entre sus equipos de CGNAT y el equipo en las instalaciones de sus clientes (resumen y secciones 1 y 7, consultado en octubre de 2026). Si el router de casa es el equipo de ese enlace, una dirección de ese bloque aparecería en el salto justo después de él. Ese es el salto 2, el que no respondió.

Con CGNAT, una redirección de puertos en tu router, por sí sola, no puede recibir las conexiones enviadas a la dirección IPv4 pública. RFC 6888 describe un NAT de nivel de operador como una función de la red del proveedor que comparte una dirección IPv4 entre varios suscriptores. Los suscriptores tienen poco o ningún control sobre él ("limited or no control"), mientras que normalmente tienen control total ("typically have full control") sobre un NAT en sus propias instalaciones (sección 2, consultado en octubre de 2026). Una redirección de puertos es un ajuste de ese segundo tipo de NAT.

Desde un VPS, ninguno de los 8 puertos respondió en la dirección IPv4 pública

Presencié esta prueba en octubre de 2026; se ejecutó desde un VPS, un servidor en la nube y no mi propio hardware. Desde allí, un script intentó una conexión TCP a cada uno de los 8 puertos de la dirección IPv4 pública de la conexión de casa, entre ellos el 22, el 80 y el 443, y dio a cada uno 6 segundos para responder. Para esta prueba no se configuró ninguna redirección de puertos. Antes de los puertos de casa, el script se comprobó a sí mismo contra destinos con respuestas conocidas.

La ejecución duró 56 segundos. El puerto vacío y los 8 puertos de casa, nueve sondas en total, esperaron cada uno los 6 segundos completos: 54 de los 56. Cada "sin respuesta" fue una espera real, no la herramienta fallando al instante.

El puerto 25 agotó el tiempo de espera; el 587 conectó

En octubre de 2026, un equipo de la red de casa intentó conexiones TCP por IPv4 a portquiz.net, un servidor público preparado para probar puertos. Su página principal dice que escucha en todos los puertos TCP para que puedas probar cualquier puerto TCP saliente ("listens on all TCP ports, allowing you to test any outbound TCP port"; consultada en octubre de 2026). Cada conexión tuvo un tiempo de espera de 10 segundos. El barrido usó /dev/tcp de bash, y el 25 y el 445 se volvieron a probar con socket.create_connection de Python y timeout=10.

Los dos puertos de envío de correo, el 465 y el 587, conectaron. Los puertos 25 y 445, no.

Aún sin probar

• Por qué no responde el salto 2. Una traza en la que respondiera mostraría qué hay justo después del router de casa, y una dirección de 100.64.0.0/10 en ese punto es justo aquello para lo que RFC 6598 reserva ese bloque.
• Dónde se descartan el 25 y el 445. Eso requiere la misma prueba desde otra red.
• IPv6 entrante. Nada en esta página muestra si una conexión por IPv6 puede llegar a un servidor en casa.

La página de ayuda de Starlink What IP address does Starlink provide? describe su política IPv4 predeterminada en términos generales: la configuración IPv4 predeterminada usa NAT de nivel de operador (CGNAT) con espacio de direcciones privado del prefijo 100.64.0.0/10 ("uses Carrier-Grade Network Address Translation (CGNAT) using private address space from the 100.64.0.0/10 prefix"), y esa política no permite tráfico entrante ("does not allow inbound traffic"). La misma página dice que los clientes que necesitan tráfico entrante deberían plantearse usar un router de terceros y, si hace falta tráfico IPv4 entrante, un plan de servicio de Starlink con la opción de IPv4 pública ("should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option"), que es una opción de los planes Priority (consultada en octubre de 2026). Es lo que dice Starlink de su servicio, no un resultado de la traza de esta página, y esta página no prueba ninguna de las dos vías. Lo que supone cada vía está en la página sobre dejar un proveedor por cable.

Una forma de sortear la falta de una dirección IPv4 pública es una conexión que se inicia dentro de tu red. La documentación de Cloudflare sobre Cloudflare Tunnel dice que su conector, cloudflared, abre solo conexiones salientes hacia la red de Cloudflare, de modo que un servidor puede servir tráfico a través de Cloudflare sin una dirección IP enrutable públicamente (página actualizada por última vez en agosto de 2026, consultada en octubre de 2026). Esta página no lo prueba.

Consulta qué significan estos resultados si estás eligiendo una conexión para un homelab.