NAT o tu propia IPv4: lo que un solo puerto redirigido puede y no puede hacer

Casi todo el mundo descubre qué significa NAT unos diez minutos después de comprarlo. Nginx arranca, curl localhost devuelve la página y el navegador del portátil se queda dando vueltas. No hay nada roto. Simplemente el servidor no tiene una IPv4 pública propia, y su única puerta de entrada es un puerto redirigido para SSH.

Esa única puerta da para una cantidad sorprendente de trabajo y se queda muy corta para algunas cosas muy habituales. Si todavía estás eligiendo entre los dos tipos de tarifa, nuestro artículo anterior ¿IP dedicada o VPS con NAT? plantea la única pregunta que lo decide. Este trata de convivir con la respuesta: qué puede hacer un servidor NAT en la práctica, dónde choca con un muro y cómo salir cuando se te queda pequeño.

Lo que recibes de verdad

Un servidor NAT tiene una dirección privada detrás de nuestra pasarela. El panel muestra un host y un puerto personal, y te conectas así:

ssh -p 20123 root@host

Ese puerto apunta al puerto 22 de tu servidor. Todos los demás puertos de entrada por IPv4 están cerrados desde fuera, y no hay opción de redirigir más. La salida es otra historia: el servidor llega a cualquier sitio de internet salvo a los puertos SMTP 25 y 465, que están cerrados en todas las tarifas, con NAT o sin él. Las reglas completas están en Red y puertos.

Un detalle más que a algunos les importa: la dirección saliente no es tuya. El tráfico sale por una dirección que no controlas, así que no puedes configurar su DNS inverso ni construir sobre ella una reputación de remitente.

Lo que funciona bien detrás de un solo puerto

Todo lo que inicia la conversación por su cuenta. Y eso es más de lo que parece:

• Bots que consultan. Un bot de Telegram con long polling, un bot de Discord en su conexión gateway, un bot de trading que habla con la API de un exchange. Todo saliente.
• Agentes de IA. Un agente que llama a APIs de modelos, navega, escribe archivos y ejecuta código no necesita que nadie le llame. Necesita CPU, memoria y salida a internet.
• Workers y scrapers. Todo lo que recoge tareas de una cola, rastrea páginas o sincroniza datos con un horario.
• Máquinas de build y runners. Los runners de CI suelen registrarse ellos solos en el servidor y van a buscar el trabajo, así que con NAT están a gusto.

Para esta carga, la tarifa más barata sobra, sinceramente. Nano cuesta 3 $ al mes por 2 vCPU, 1 GB de RAM y 15 GB de disco; Small, 8 $ por 4 vCPU, 4 GB y 35 GB. Tienes la lista completa en una página propia de las tarifas NAT.

Donde un solo puerto no basta

El muro es todo aquello en lo que otra persona tiene que iniciar la conexión.

La web es el caso evidente. Los navegadores se conectan al puerto 443 (y al 80 para la redirección), y en una tarifa NAT esos puertos no existen vistos desde fuera. Tampoco sirve un puerto no estándar, al menos no de una forma que los visitantes vayan a aceptar.

Tu propio dominio con HTTPS choca dos veces con el mismo muro. Puedes apuntar un registro DNS a la dirección de la pasarela, pero nada de lo que llegue allí se reenvía a tu servidor salvo tu puerto SSH. Y la forma habitual de obtener un certificado gratuito comprueba tu servidor en el puerto 80 o 443.

Los webhooks fallan en silencio. Avisos de pago, una plataforma de bots que envía actualizaciones, un servidor Git que anuncia un commit nuevo: todos tienen que llegar a ti. El bot que funcionaba perfectamente con long polling deja de funcionar justo cuando lo pasas a webhooks.

Los puntos de acceso VPN, los servidores de juegos y los de correo necesitan puertos de entrada por definición. Igual que cualquier cosa que quieras abrirle a un compañero en el navegador.

Los atajos, con sinceridad

IPv6. Los servidores Linux nuevos reciben una dirección IPv6 pública, y en las tarifas NAT llega al servidor directamente, en cualquier puerto. Si todos los clientes de tu servicio son tuyos (tu portátil, tus otros servidores, una sonda de monitorización con IPv6), funciona bien. Para una web pública, no: una parte de los visitantes sigue en redes sin IPv6 y nunca llegará a cargar la página. Las tarifas Windows de momento solo tienen IPv4.

Un túnel. Puedes ejecutar un pequeño agente que mantiene una conexión saliente con un relé en otro sitio, que a su vez devuelve el tráfico público por el túnel. Funciona, y para una demo o un panel interno es razonable. Para algo que importe, has metido a un tercero en medio de cada petición y una pieza más que puede romperse a las tres de la madrugada.

Un túnel SSH para ti. Si la única persona que necesita el panel de administración eres tú, no lo expongas en absoluto. Redirígelo por el puerto SSH que ya tienes:

ssh -p 20123 -L 8080:localhost:8080 root@host

Después abre http://localhost:8080 en tu máquina. Es el truco más infravalorado en un servidor NAT, y además es más seguro que poner el panel en internet.

Mi opinión sincera: IPv6 y los túneles SSH son buenas herramientas. Un servicio público permanente que pasa por un túnel solo porque el servidor no tiene IPv4 suele ser señal de que el NAT ya se te ha quedado pequeño.

Pasar a tu propia IPv4 sin reinstalar

No hace falta reconstruir nada. Abre el servidor en el panel, elige «Cambiar de tarifa» y una tarifa con IP dedicada del mismo tamaño o mayor. El servidor se reinicia una vez y vuelve con su propia IPv4 pública, su disco y todo lo que instalaste. Los puertos 80, 443 y lo que abras en el cortafuegos pasan a ser accesibles, y SSH se mueve al puerto 22 de siempre. Los detalles están en Cambiar de tarifa.

Conviene saber algunas cosas antes de pulsar:

• Pagas la diferencia prorrateada por lo que queda del periodo actual, desde tu saldo. Nano-IP cuesta 8 $ al mes frente a 3 $ de Nano; Small-IP, 16 $ frente a 8 $.
• Hace falta una dirección libre en la ubicación de tu servidor. Si ahora no la hay, el panel te lo dice antes de cobrar nada.
• Si editaste a mano la configuración de red dentro del servidor, revísala después del reinicio. En una imagen estándar se aplica sola.
• Haz antes una copia de seguridad. Es un solo reinicio, pero siguen siendo tus datos.

Donde el NAT no encaja, y donde la IPv4 tampoco

El NAT es mala elección para todo lo público, para todo lo que recibe webhooks y para todo lo que necesita una dirección fija que alguien añada a una lista de permitidos. No pierdas días intentando esquivarlo. La diferencia de precio entre Nano y Nano-IP es de 5 $ al mes.

Pero una IPv4 dedicada tampoco es magia. No hará que te deje entrar una web que bloquea direcciones de centros de datos, ni salvará a un scraper de los límites de peticiones, porque esas decisiones dependen de la red en la que estás, no de quién más usa la dirección. Y si todo tu proyecto son un par de bots y un agente, pagar una IPv4 a la que nunca se conectará nadie es tirar el dinero.

Si de todos modos tienes pensado mudarte a algo más grande, mudar un VPS sin cortes explica el orden de los pasos, y cómo leer las especificaciones de un VPS te ayuda a comparar tarifas.