El problema

En aquel artículo, casi al final de todo, comentaba que hacía falta aplicar una solución para que el tráfico XMPP del resto de puertos (5000, 5222,… todos los que no son el 80 ó el 443) fuese reenviado desde el VPS a mi servidor en casa.

Probé algunas cosas con la configuración de NGINX y su módulo streams, pero no funcionó, así que voy a describir aquí cómo acabé usando las capacidades de filtrado de paquetes de Linux (el núcleo mismo) a través de iptables (en inglés).

Mi solución está basada y adaptada a partir de lo explicado en este artículo (en inglés) de Ryan Welch.

Al final del artículo, en cualquier caso, dejaré las configuraciones que intenté aplicar en NGINX para procesar tráfico TCP y UDP en general. Quizá lo necesitemos más adelante, o a lo mejor decides probarlo y comentarme qué es lo que hice mal.

Solución

Como comentaba antes, Linux (NO GNU/Linux, sino “Linux” sin más, el núcleo) tiene funcionalidades de filtrado de paquetes de red incluidas, que podemos configurar para nuestros propios fines.

Para configurar la redirección de tráfico en el VPS, entramos por SSH y habilitaremos IP forwarding en el núcleo:

sudo sysctl -w net.ipv4.ip_forward=1

Esto puede que se aplique entre arranques, o no, dependiendo de tu distribución. Para asegurarte, edita el fichero /etc/sysctl.conf y descomenta la línea net.ipv4.ip_forward=1.

Tras ello, ya podrás redirigir puertos y rangos de puertos con instrucciones como la siguiente:

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5222 -j DNAT --to-destination <IP Destino>:5222
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5222 -j MASQUERADE

Y, para rangos de puertos:

iptables -A PREROUTING -t nat -p udp -i eth0 -m multiport --dports 49152:65535 -j DNAT --to-destination <IP Destino>:49152-65535
iptables -A POSTROUTING -t nat -p udp -d <IP Destini> -m multiport --dports 49152:65535 -j MASQUERADE

Vas a tener que cambiar los puertos del ejemplo por los tuyos propios, así como poner tu propia dirección IP de destino en lugar del texto <IP Destino>.

Para el caso de XMPP hay que añadir todas las reglas de renvío correspondientes a sus puertos, cambiando el texto <IP Destino> por la dirección IP del servidor de casa, patata en el artículo previo de la serie, y teniendo en cuenta que la dirección que tenemos que configurar es la de patata en Tailscale.

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5222 -j DNAT --to-destination <IP Destino>:5222
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5222 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5269 -j DNAT --to-destination <IP Destino>:5269
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5269 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5000 -j DNAT --to-destination <IP Destino>:5000
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5000 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 3478 -j DNAT --to-destination <IP Destino>:3478
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 3478 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 3479 -j DNAT --to-destination <IP Destino>:3479
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 3479 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 3478 -j DNAT --to-destination <IP Destino>:3478
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 3478 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 3479 -j DNAT --to-destination <IP Destino>:3479
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 3479 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5349 -j DNAT --to-destination <IP Destino>:5349
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5349 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5350 -j DNAT --to-destination <IP Destino>:5350
iptables -A POSTROUTING -t nat -p tcp -d <IP Destino> --dport 5350 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 5349 -j DNAT --to-destination <IP Destino>:5349
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 5349 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 5350 -j DNAT --to-destination <IP Destino>:5350
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> --dport 5350 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 -m multiport --dports 49152:65535 -j DNAT --to-destination <IP Destino>:49152-65535
iptables -A POSTROUTING -t nat -p udp -d <IP Destino> -m multiport --dports 49152:65535 -j MASQUERADE

Prueba que todo funciona y graba las reglas de iptables con sudo iptables-save > /etc/iptables/rules.v4, de tal forma que se apliquen cada vez que reinicies el VPS.

En su artículo, Ryan comentaba otras configuraciones adicionales para temas tales como control de congestión. Consulta ese artículo para saber más, y aplica todo aquello que te sea de utilidad.

NGINX con tráfico TCP y UDP genérico

Esta parte del artículo no está del todo probada, porque no me acabó de funcionar para la instalación del servidor XMPP Snikket. Sin embargo, de acuerdo a su documentación, ésta es la forma en la que se configura NGINX para tráfico que no es Web.

Instala libnginx-mod-stream para habilitar el soporte a proxies inversos TCP y UDP.

Modifica /etc/nginx/nginx.conf para añadir un bloque stream:

stream {
        include /etc/nginx/streams-enabled/*;
}

Tras ello, crea los directorios correspondientes siguiendo el mismo esquema existente para las webs: sudo mkdir -p /etc/nginx/streams-available /etc/nginx/streams-enabled

Crea un fichero /etc/nginx/streams-available/tcpudpservice.example.com.conf con reglas como las siguientes:

# Puerto TCP (tráfico no HTTP):
server {
        listen 5222;
        proxy_pass <IP Destino>:5222;
}

# ...

# Puerto UDP:
server {
        listen 3478 udp;
        proxy_pass <IP Destino>:3478;
}

# ...

# Se aceptan rangos, también. En este caso, fíjate
# en el uso de $server_port en la sentencia proxy_pass.

server {
        listen 49152-65535 udp;
        proxy_pass <IP Destino>:$server_port;
}

En caso de definir rangos de puertos muy grande, como los que propone Snikket para conversaciones de audio y vídeo por XMPP en instalaciones con muchos usuarios, NGINX devolverá un error al tener demasiados ficheros abiertos. La configuración de Snikket espera poder tener hasta 16384 conexiones UDP abiertas al mismo tiempo.

Si queremos resolver esto en lugar de reducir el rango de puertos UDP, hay que aumentar el parámetro LimitNOFILE de NGINX. Para eso, ejecuta sudo systemctl edit nginx.service; esto abrirá un fichero de extensión de la definición del servicio

Escribe lo siguiente y graba los cambios:

[Service]
LimitNOFILE=65535

Tras ello, en el preámbulo de /etc/nginx/nginx.conf (fuera de cualquier bloque http, events o stream), añade la línea worker_rlimit_nofile con un valor menor a 65535 (30000 funciona para Snikket), e incrementa el valor de worker_connections dentro de events:

...
include /etc/nginx/modules-enabled/*.conf;

worker_rlimit_nofile 30000;

events {
        # worker_connections 768;
        # 3 veces 8192 será suficiente
        worker_connections 24576;
        # multi_accept on;
}

...

Como dije antes, esta configuración no me sirvió para XMPP, pero puede ser útil para otros casos de uso.

Este texto detalla los pasos a seguir para conectar un proxy inverso (NGINX) instalado en un servidor A, y dar acceso a servicios web instalados en otra máquina diferente, un servidor B. Si la máquinas están en ubicaciones o redes diferentes, la conectividad la podremos resolver mediante varias alternativas, como una VPN.

En mi caso concreto, esto sirve para instalar NGINX en un VPS, y usarlo para exponer mis servicios alojados en un servidor que tengo en casa, “barcas”. Para conectar las dos máquinas y que NGINX pueda redirigir el tráfico a esos servicios, he usado Tailscale.

Este artículo continúa la serie que empezó con “Cambios en mi red de la mano de XMPP”. Si te preguntas por qué querríamos hacer esto, o qué valor tiene esta configuración, visita ese enlace.

Solución

Para llevar a cabo esta solución necesitarás:

1. Un servidor VPS contratado con tu servicio de alojamiento de confianza, al que poder acceder por SSH.
2. Un servidor en tu casa, con al menos un servicio aceptando conexiones HTTP. Por ejemplo, en el puerto 5000 (0.0.0.0:5000). A este servidor lo llamaremos patata en el resto del artículo, por claridad.
3. Una cuenta gratuita en Tailscale. En general, valdría con cualquier otro proveedor de VPN, pero es preferible que esté basada en WireGuard, porque ofrece un mejor rendimiento que OpenVPN.
4. Opcionalmente, o para que esto tenga sentido, un dominio con sus registros de DNS apuntando al VPS que mencionamos en el punto 1.

En las instrucciones de este artículo supondré que ambos servidores (el VPS y patata) tienen instalada una Ubuntu LTS Server (por ejemplo, la 24.04).

Si no hay problemas, en 20 minutos deberías tenerlo todo listo.

Servidor en casa

Nos conectaremos a patata, donde está nuestro servicio web esperando peticiones en el puerto 5000.

Instalamos Tailscale y autenticamos a patata en nuestra cuenta. Esto asociará una dirección IP dentro de la VPN a patata:

# Las órdenes para instalar tailscale no las reproduzco 
# porque podrían cambiar en cualquier momento.

sudo tailscale up
# Seguimos las instrucciones por pantalla

# Habilitamos Tailscale como servicio de sistema permanentemente
sudo systemctl enable tailscaled --now

# Obtenemos la IP de esta máquina en la tailnet y la anotamos.
tailscale ip -4
100.85.67.22

En el panel de control de Tailscale podremos ver su nombre local, además de la IP devuelta por la última orden.

También podremos configurar la máquina para que no haya que re-introducirla en la red, desactivando la expiración de la clave usada para autenticar la máquina en Tailscale.

Opcionalmente, podemos activar el “MagicDNS” para podernos referir a ambas máquinas mediante un nombre, en lugar de mediante una dirección IP, sin tener que configurar nada localmente en las máquinas.

Una vez la máquina está en Tailscale, debemos abrir el puerto 5000 en el cortafuegos de patata, si es que no lo habíamos hecho ya, para que pueda recibir peticiones desde el VPS por dicho puerto.

sudo iptables -A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT

A este respecto:

1. Si no tienes iptables-persistent instalado, es el momento de instalarlo para poder grabar las reglas de cortafuegos de tal forma que se apliquen con cada reinicio de la máquina.

sudo apt install iptables-persistent 
sudo iptables-save > /etc/iptables/rules.v4

2. Personalmente, abro los puertos en todos los interfaces y no sólo en el de Tailscale.
   • Al no tener que abrir ese puerto en el router, no estoy haciendo nada que me deje demasiado expuesto.
   • Al hacerlo así, no necesito acceder por Tailscale a patata cuando, estando en casa, necesito hacer alguna prueba.
   • Cada caso es distinto: decide qué hacer tú mismo con tu cortafuegos dependiendo de lo crítico que sea el servicio que estás configurando, y lo sensibles que sean los datos que gestiona.

VPS

En segundo lugar, nos conectamos al VPS por medio de SSH e instalamos un proxy inverso. Aunque no vayamos a tener más de un servicio escuchando en los puertos 80 y 443, configurar y entender un proxy inverso es más fácil que configurar y entender reglas de reenvío de tráfico y DNAT en un cortafuegos como iptables.

En mi caso, suelo usar NGINX.

sudo apt update && sudo apt install nginx

Instalamos Tailscale y repetimos los mismos pasos al respecto que en el caso de patata. Anotamos la dirección IP de el VPS en “la tailnet”, por ejemplo 100.85.77.36.

Obtenemos un certificado de Let’s Encrypt para nuestro dominio, con CertBot. Para esto:

• Debemos configur previamente los registros DNS de nuestro dominio, ejemplo.com, para que apunten a la IP pública (no a su IP en Tailscale) del VPS en el que estamos trabajando.
• Es posible tengamos que parar NGINX para esto (sudo systemctl stop nginx), dependiendo de nuestros proveedores de dominio y los plugins de CertBot disponibles para interactuar con él.

sudo certbot certonly --standalone -d ejemplo.com
...
...
Successfully received certificate.
Certificate saved at: /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
Key is saved at:      /etc/letsencrypt/live/ejemplo.com/privkey.pem;
...
...

Configuramos el servicio en el proxy inverso, poniendo en la sentencia proxy_pass la IP de nuestro servidor patata en Tailscale. Para ello, en /etc/nginx/sites-available/ creamos un fichero de configuración, por ejemplo ejemplo.com.conf para una web https://ejemplo.com.

upstream ejemploweb {
        # Sustituye [IP o nombre de máquina] por el valor de tu 'patata'
        # **en Tailscale**.
        # 100.85.67.22 en el texto del artículo.
        server [IP o nombre de máquina]:5000;
        keepalive 64;
}

server {
        server_name ejemplo.com;
        listen 80;

        location / {
                return 301 https://$host$request_uri;
        }
}

server {
        server_name ejemplo.com;
        listen 443 ssl http2;

        # Other SSL stuff goes here
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;

        ssl_certificate     /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ejemplo.com/privkey.pem;

        location / {
                # The final `/` is important.
                proxy_pass http://ejemploweb/;
                add_header X-Frame-Options SAMEORIGIN;
                add_header X-XSS-Protection "1; mode=block";
                proxy_redirect off;
                proxy_buffering off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-Port $server_port;
                proxy_read_timeout 90;
        }
}

Creamos un enlace simbólico a este fichero en /etc/nginx/sites-enabled, probamos la configuración de NGINX y, si todo va bien, la recargamos.

cd /etc/nginx/sites-enabled/
sudo ln -s ../sites-available/ejemplo.com.conf
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# Si hemos detenido el servicio de NGINX para obtener el certificado, 
# lo arrancamos; si no:
sudo systemctl reload nginx

En este punto, deberíamos poder interactuar con nuestro servicio en patata desde https://ejemplo.com.

Posibles errores que te puedes encontrar

• El navegador no muestra nada, el servicio no contesta. Si hay actividad en los logs de NGINX en el VPS (sudo tail -f /var/log/nginx/access.log), y la petición se abandona tras un tiempo (timeout), hay varias posibles causas que me he encontrado con mi limitada experiencia. En patata:
  • El servicio al que quieremos acceder a través de NGINX no está funcionando, y tenemos que arrancarlo,
  • o el servicio está expuesto en el puerto 5000 de un interfaz de red específico, en lugar de 0.0.0.0 (que significa todos los interfaces de red de patata), y que no es el de Tailscale; por ejemplo, en 127.0.0.1,
  • o hemos hecho algo mal con el cortafuegos y la petición se está rechazando de esta forma.
• La configuración de NGINX es correcta (sudo nginx -t dice que 👍), pero NGINX no arranca o se muere al recargar la configuración. La causa más frecuente es que NGINX no se puede comunicar con patata, al que estaríamos apuntando con la sentencia proxy_pass, porque no lo encuentra.
  • O bien hemos cometido un error al configurar el proxy_pass,
  • o bien NGINX ha intentado establecer contacto con patata antes de que Tailscale estableciese el túnel, por ejemplo si esto ocurre tras reiniciar el VPS,
  • o bien el servicio de Tailscale se ha parado en alguna de las dos máquinas.
  • Esta causa se confirma con el mensaje host not found in upstream en la salida de sudo systemctl status nginx:

nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/nginx.service.d
             └─override.conf
     Active: active (running) since Fri 2025-08-29 11:05:51 UTC; 3 days ago
       Docs: man:nginx(8)
    Process: 1154 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 1156 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 58676 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=1/FAILURE)
   Main PID: 1157 (nginx)
      Tasks: 3 (limit: 1110)
     Memory: 46.9M (peak: 200.2M)
        CPU: 29min 57.349s
     CGroup: /system.slice/nginx.service
             ├─1157 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1158 "nginx: worker process"
             └─1159 "nginx: cache manager process"

...
Sep 02 05:32:49 vps-hostingprovider nginx[58676]: 2025/09/02 05:32:49 [emerg] 58676#58676: host not found in upstream "100.85.77.22" in /etc/nginx/sites-enabled/ejemlo.com.conf>
Sep 02 05:32:49 vps-hostingprovider systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Sep 02 05:32:49 vps-hostingprovider systemd[1]: Reload failed for nginx.service - A high performance web server and a reverse proxy server.
lines 1-28/28 (END)

• Recibimos un código de estado HTTP 502. Esto quiere decir que, si bien NGINX está funcionando correctamente, el servicio al que nos conectamos (expuesto en el puerto 5000 de patata), está devolviendo errores.
  • Si haces una prueba local en patata y el servicio funciona, casi seguro que se trata de un tema de proxies de confianza. Describir el problema en detalle excede los objetivos de este artículo, pero en resumen se trata de que tienes que especificar en la configuración de ese servicio, en patata, que NGINX está instalado en una máquina diferente, el VPS, y configurar la dirección del VPS en Tailscale como proxy de confianza. Consulta los logs del servicio para confirmar esta hipótesis.
  • Esto no es un problema, es una característica de seguridad bastante interesante.
  • Por ejemplo, esto me pasó con mis instancias de Mastodon y de Nextcloud. En ambos casos, la documentación contenía las soluciones: Mastodon – trusted proxies, Nextcloud – trusted proxies
  • Depende de cómo esté implementado el servicio que estamos intentando arreglar, puede ser que acepte un proxy de confianza tanto como nombre de máquina o como direccion IP, o sólo como IP. Ármate de paciencia y si no te funciona con el nombre de la máquina no te desesperes.

En éste os voy a contar cuáles son esos problemas, por qué surgen, por qué los quiero resolver y cómo los he resuelto, pero desde un punto de vista de diseño por el momento. No vas a encontrar instrucciones de terminal para resolver todo esto, sino el contexto necesario para saber qué estoy intentando resolver; las instrucciones detalladas vendrán en los siguientes artículos.

Hasta ahora, todos mis servicios alojados bajo mi impresora eran servicios Web, es decir, basados en comunicaciones a través de los puertos 80 y 443 (HTTP y HTTPs). Estos puertos eran suficientes para comunicar todos mis servicios con mis dispositivos o con mi navegador, o con otros servidores en el caso de mi instancia de Mastodon. Para poder atender a tantos servicios tras los mismos puertos, uso NGINX como proxy inverso:

A diferencia de mis otros servicios, XMPP usa más puertos TCP y UDP que el 80 y el 443: 5000, 5222, 5269,… En el caso de Snikket como, supongo, toda otra serie de alternativas, los puertos 80 y 443 también se usan para proporcionar un panel de control Web y poder administrar usuarios y salas de chat.

Sobre el papel, la configuración para instalar Snikket sería la siguiente:

• Configurar los puertos 80 y 443 en NGINX para poder usar el panel de control de usuarios y conversaciones de Snikket.
• Configurar acceso directo a todo el resto de los puertos de Snikket: 5222, 5269,… ésta es la lista completa (en inglés). Como no son puertos compartidos entre varios servicios, no hace falta configurarlos en un proxy inverso.
• Configurar las DNS de mi servicio de XMPP en mi proveedor de dominios, que es Cloudflare.

Esta configuración, que a priori tendría buena pinta, se resume en esta figura:

Sin embargo, esto tiene un problema que no es evidente, y la configuración de arriba no funciona sin más. Las características de seguridad de Cloudflare que están disponibles para las cuentas gratuitas en forma de “el proxy de Cloudflare” sólo soportan los puertos 80 y 443. Con el proxy de Cloudflare activado, todo el tráfico que no es web (80 y 443) se descartaba, por lo que ninguno de los puertos que entran en juego en las conversaciones de XMPP llegaba a mi servidor.

Desactivando el proxy de Cloudflare para la configuración de los subdominios de Snikket todo funciona, pero queda así:

Desactivar el proxy de Cloudflare no es ideal, porque expone la IP del servidor al resto de internet. Mi servidor está en casa, por lo que un ataque de denegación de servicio que, por puro azar, incluyese la dirección IP que mi operador de acceso a internet me asigna, tiraría por tierra toda mi red doméstica. Eso nos impediría trabajar o estudiar desde casa y, probablemente, me traería problemas con mi proveedor de servicio.

Una alternativa a esto es contratar un servidor barato en cualquier proveedor de alojamiento en la nube (un VPS) y mover toda mi configuración de NGINX a él, conectando este servidor en la nube con el servidor de mi casa mediante una VPN (la cuenta gratuita de Tailscale funciona muy bien y es más que suficiente).

• El proveedor de alojamiento en la nube protegería mi servidor porque la IP expuesta sería la suya, no la de mi casa, y este tipo de empresas protegen su infraestructura ante ataques, por lo menos a un nivel de red. Tras los puertos XMPP no hay contenido, sino un servicio de mensajería que además cifra el tráfico, así que no hay problema por perder la capa de seguridad y anti-bots que proporciona Cloudflare para estos puertos.
• Conectar el VPS a mi servidor a través de una VPN es perfecto para este caso, porque oculta la dirección IP de mi red doméstica ahorrándome configurarla en el panel de control de DNS, y también el tener que abrir puertos en mi router. Además, para todo el tráfico que iría entre la VPS y mi servidor, se aplicaría una capa de cifrado que lo protegería en caso de que, de por sí, no estuviese ya cifrado.

¿Por qué mover sólo la configuración de NGINX y no todos los servicios? Por una cuestión de recursos y precio: para ejecutar NGINX y una serie de reglas de cortafuegos, los requisitos que necesitamos son mínimos. Con un servidor que tenga 1 GB de RAM y con una CPU es más que suficiente, y eso cuesta entre 3 y 6€ al mes. Si muevo todo² necesitaría entre 8 y 16 GB de RAM, mucho más almacenamiento potencia de CPU, una solución de copias de seguridad,… Con todo ello me estaría moviendo en un rango de unos 40€, o más, al mes. Teniendo un servidor en casa donde ejecutar los servicios, moverlo todo a la VPS acarrea un coste innecesario en mi caso.

Así pues, parece que contratar una VPS sencilla para tener NGINX configurado allí, y conectarla al servidor de casa mediante Tailscale, resolvería mis problemas a un coste muy bajo (3 a 6€ al mes).

La única complicación adicional de este método es que tenemos que tener algún mecanismo para redirigir el tráfico de los puertos de XMPP (varios puertos como el 5222, 5269,… en TCP y UDP) desde el VPS hacia nuestro servidor (en casa o donde fuere). Al final lo he resuelto configurando el VPS para que haga IP forwarding y luego he configurado una serie de reglas DNAT³ en su cortafuegos.

En próximos artículos veremos más en detalle la configuración de todos los elementos.

Entre otras cosas, lo hice porque la filosofía de Ghost de obligaros a daros de alta en un perfil determinado de suscriptor para poder comentar me parecía demasiado agresiva. Es cierto, la membresía para ello era gratis, pero no dejaba de ser una barrera artificial y confusa. Por otro lado, Ghost parece más orientado a boletines de noticias (newsletter, en inglés, para los despistados) que a blogs, por varias cosas pero también por el rollo de las membresías.

Por otro lado, Hugo tiene ciertas ventajas para mí, como por ejemplo que me permite crear un blog en dos (o más) idiomas, si es que me decido a traducir todos los artículos. Así, por ejemplo, si pulsáis en la banderita australiana (🇦🇺) que está en la cabecera de la web, podréis acceder a todo el contenido en inglés. En aquellos artículos o páginas con una traducción al inglés, veréis una banderita australiana (o, si estáis en una página en inglés, veréis una banderita española si está traducida al español).

Vais a notar alguna diferencia, más allá de cambios de aspecto. Mientras Ghost es una aplicación web con un servidor y con una base de datos que genera páginas al vuelo, Hugo es un programa que yo ejecuto en mi PC para crear un sitio web estático que luego subo a un servidor web, mucho más sencillo que un servidor de aplicaciones. Eso tiene ventajas e inconvenientes. Sin entrar en demasiados detalles:

• Como ventaja inmediata, no hay ningún software del que preocuparse que se ejecute en otro sitio diferente a tu PC. Tu navegador se descarga mi web entera y te la representa.
• Como inconvemiente inmediato, en Hugo no tendremos comentarios. Algo pensaré.

Aunque a lo mejor hay algún bache por el camino, como por ejemplo que el feed RSS cambie y recibas artículos antiguos como nuevos, no hay tantos artículos como para que esto sea un gran problema; no deberías tener que preocuparte de nada. En cualquier caso, si te preocupa algo, deja un comentario mientras puedas o escríbeme un correo a gabriel arroba el dominio de este blog.

El pasado viernes 29 de noviembre estuve instalando Linux en arranque dual con Windows 11, en través de twitch. Y me ha gustado el resultado, tanto que es muy posible que haga muchos más vídeos de ahora en adelante, tanto en directo como “producidos”.

El resultado está disponible en PeerTube, en mi cuenta de veedeo.org, próximamente en YouTube, y lo puedes ver aquí mismo:

También he creado, por fin, una cuenta de Patreon para que, quien quiera, pueda apoyar este blog, el podcast y los vídeos que iré creando a medida que el tiempo y el material disponible me lo permitan.

Era genial.

Entonces, llegó Spotify, primero como inversor, y luego comprando Anchor. Al poco tiempo, todas las características sociales y el funcionamiento que comentaba arriba, como la emisora, desaparecieron del producto y nos quedamos con una plataforma de podcasting solvente, y nada más.

No voy a dar cuenta en detalle del proceso de enmierdificación de Spotify en este artículo, sino que me voy a limitar a decir que no estoy cómodo en esa plataforma desde hace tiempo, y he decidido autoalojar en casa mi propio podcast. El soporte a mi podcast me lo da ahora Castopod, una plataforma de podcasting libre y de código abierto que, además, ofrece integración con el fediverso mediante Activity Pub y soporte a múltiples características del podcasting 2.0, como la posibilidad de dejar comentarios desde tu propia aplicación de escucha de podcasts entre otras cosas.

Vamos a ver cómo se migra un podcast a Castopod. En este artículo se trata de Spotify, pero el proceso va a ser muy similar en cualquier otro caso.

Obtén Castopod

Castopod está disponible para instalar en tu propio servidor, que puede ser una VPS o una máquina sencilla conectada a internet, o puedes contratarlo en varios proveedores especializados. En castopod.org tienes acceso a información acerca de todas las opciones. Yo lo he instalado en un mini PC, en mi casa, usando Docker y NGINX como proxy inverso. Publicaré algo al respecto en lo sucesivo, pero hoy me voy a centrar en el proceso de salida de Spotify.

Opcional: obtén tu propio dominio y, si es posible, una CDN

Si lo vas a instalar en tu casa, vas a necesitar un dominio. Si lo usas ofrecido por alguno de los proveedores, probablemente puedas usar un subdominio proporcionado por ellos.

En cualquier caso, como un podcast sirve archivos de cierto peso, es buena idea contratar un servicio que te ofrezca una red de distribución de contenidos (CDN) con presencia en múltiples geografías: actuará de caché, relajando los requisitos de ancho de banda de tu proveedor, y además acelerará el acceso a tu podcast desde geografías lejanas. Personalmente, uso la cuenta gratuita de Cloudflare para los dos asuntos: dominio y CDN.

Importa tu Podcast en Castopod

Una vez Castopod está funcionando en tu servidor, es hora de importar tu podcast en Castopod. Esto se hace indicando la dirección del feed RSS a Castopod en su panel de control, así como el nombre de usuario en el fediverso, la categoría y el idioma del contenido.

![)Formulario de importación de un podcast en Castopod Es importante tener en cuenta que Castopod va a reinterpretar todo el feed y a validarlo. Uno de los problemas que tuve derivados de este aspecto es que, si a alguno de tus episodios le faltan las notas (el contenido del campo <description />), el proceso va a fallar, tendrás que corregir el episodio en concreto, esperar a que Spotify republique tu feed, y reanudar el proceso donde se interrumpió. En mi caso, llevó unos cuantos intentos:

Opcional: activa las estadísticas OP3

Las estadísticas que ofrece Castopod por defecto son bastante buenas, pero si te interesa la iniciativa Open Podcast Prefix Project, OP3, es un buen momento para unirte a ella activando las estadísticas con un sólo click en el formulario de edición de tu podcast.

Redirige tu antiguo feed al nuevo, permanentemente

Éste es el paso más sencillo, y más crítico. En Spotify para Podcasters, en el panel de edición de tu podcast, encontrarás un campo de texto para introducir un nuevo feed al que redirigir el antiguo. Esta redirección se implementa mediante un código de estado del protocolo HTTP, 301, que indica a los clientes, índices, buscadores y directorios de podcasting que el feed se ha mudado y nunca volverá a Spotify. En el cuerpo de la respuesta que acompaña a ese estado de redirección permanente 301 está la dirección del nuevo feed. El comportamiento esperado para clientes HTTP (cualquier aplicación o servicio que quiera acceder al feed) cuando reciben una respuesta con estado 301 es actualizar sus registros a la nueva dirección y no volver a intentar acceder a la antigua nunca más.

A partir de este momento, y en un tiempo indeterminado, todos tus suscriptores empezarán a recibir contenido por el feed nuevo, y si tienes la misma experiencia que yo, de una forma totalmente transparente.

⚠️ Cuando esto pase, perderás el control de tu podcast en Spotify para Podcasters

Esto es algo de lo que Spotify no te avisa claramente, pero cuando Spotify perciba que el podcast ya no está bajo su control, perderás acceso a funciones de edición del mismo, e incluso a la posibilidad de borrar los datos del mismo en Spotify.

Aún cuando veas que esto está pasando, no borres aún tu cuenta de Spotify para Podcasters: si algún rezagado no ha recibido la instrucción de redirección y borras tu cuenta, se borra la redirección, con lo cual podrías perder oyentes. Personalmente, yo voy a borrarla pasado un mes.

⚠️ Escoge cuidadosamente el momento de hacer esto si alojas tu nuevo podcast en tu casa.

En el momento en el que actives la redirección en Spotify, servicios de directorio que probablemente no sepas que estaban indexando tu feed recibirán las coordenadas del feed nuevo. Estos servicios de directorio usan procesos tipo arañas (mala traducción de web crawlers) para recorrer el feed y reindexarlo todo.

El cambio desde Spotify para Podcasters a Castopod es muy profundo. En términos de la propia estructura del feed, de dónde están alojados los ficheros, y del nombre de los mismos, el efecto es que todos estos procesos perciben tu podcast como una reedición completa. Como decimos en España, a este feed no lo reconoce ni su padre. Esto hace que todos estos actores invaliden todos los datos previos y lo recorran todo de nuevo, descargando todos y cada uno de tus episodios, metadatos, imágenes… todo. Y en este momento, aunque tengas CDN, su caché todavía está vacía, por lo que todas las peticiones van a ir directas a tu casa.

Estos servicios tienen una capacidad de cómputo y de red inmensamente mayor que la de tu casa, por lo que todos* ataquen tu feed a la vez*, tu conexión a internet va a experimentar un pico de tráfico de subida muy significativo, que puede afectar a tu conectividad, especialmente si hay alguien trabajando desde casa.

Por eso, mejor hazlo por la noche. No seas como yo 😅

Solicita el traspaso de tu Podcast a tu propiedad en los distintos directorios (que te interesen)

Esto es importante.

Me voy a centrar en Apple Podcasts, pero es fácil entender que esto deberías hacerlo allá en donde te interese tener presencia, en tu caso particular.

Acabas de redirigir tu feed a Castopod, tu conexión a internet en casa las ha pasado canutas, y has tenido que dar explicaciones a tu mujer e hijos de por qué internet iba como una patata, pero todo ha vuelto a su cauce normal, todo funciona y los primeros oyentes que sabían que ibas a cambiar esto te felicitan, te dicen que las descargas van más lentas…

Sin embargo, los directorios de podcasting como Apple Podcasts no te tienen registrado como el autor o el responsable del mismo a la hora de enviarte alertas y avisos con respecto a tu podcast. Situaciones en las que te podrías ver involucrado y que te interesaría resolver con Apple, como una potencial violación de los Términos y Condiciones de su servicios de directorio, no te serán notificadas.

Por otro lado, tampoco tienes control sobre tu podcast en Spotify para Podcasters, que es a donde Apple enviaría este tipo de mensajes en caso de conflicto. Spotify te ha dado la patada en cuanto la redirección se ha vuelto efectiva.

Estás en tierra de nadie.

Es hora de ponerse en contacto con Apple Podcasts Connect y solicitar que te den control sobre tu podcast.

Para eso, ármate con tu fluidez en el idioma de Shakespeare, porque creo que el formulario no se ofrece en Español, y haz lo siguiente (efectivo en Mayo de 2024):

1. Entra en Apple Podcasts Connect, o regístrate si no tienes cuenta.

2. Abajo de todo, selecciona “Contact Us”

3. En el formulario que aparece, rellena tus datos y selecciona como tema de consulta “Missing Podcast(s)” dentro de “Content Management”. Tendrás que introducir los siguientes datos:

4. El título del podcast ("Podamigos del cocido")

5. El id del podcast. Entiendo que se trata de los números al final en la URL del podcast en Apple Podcasts: “id817487481”.

6. La URL completa a la página del podcast en Apple Podcasts.

7. La URL del nuevo feed.

8. En el cuerpo del mensaje, indica que has migrado tu podcast desde Spotify a otro hosting, indica también la del anterior por si acaso el operador que te atienda todavía tiene el antiguo feed en sus cachés, y pide instrucciones como te gustaría que te las pidiesen a ti.

Este fue el mensaje enviado, nada fuera de lo común:

Good afternoon.

I am writing as the author of the show “sobre la marcha”, which was previously hosted on Spotify for Podcasters. I recently re-hosted the show on my own hosting server, and I would like to claim ownership and be able to manage it under my Apple Podcasts Connect dashboard. I hope this is the right method / channel to request so.

Looking forward to hearing from you,

~Gabriel Viso Carrera

PS – before today, the show’s feed was “https://anchor.fm/s/dd4f78/podcast/rss". As part of the migration, it has been placed a 301 permanent redirection to the feed I filled in this form; please take it into consideration of you see that the redirection hasn’t been followed in your systems yet. Please note that no further episodes will be appearing in such feed.

Te enviarán un correo en un plazo de un par de días, pidiéndote más datos (como el ID de tu cuenta en Apple Podcasts Connect), y dándote un código numérico que deberás introducir en algún campo del feed. Por ejemplo, mí me dieron como opciones el campo de <copyright />, <keyword /> o <verification />.

En negrita los aspectos clave que nos piden en esta respuesta de ejemplo, que es lo que me contestaron a mí con algunas cosas cambiadas.

Hello Gabriel,

Thanks for reaching out to us. I hope you’re doing well.

To get access to the show in Apple Podcasts Connect, we can transfer the ownership of it to your account.

To transfer ownership, enter the six-digit authorization code “381234” in the verification, keyword, or copyright fields of your RSS feed.

You can update the six-digit authorization code on your hosting provider’s platform or edit the metadata tags in your RSS feed. If you need assistance with this update, contact your hosting provider. We’ll review your request after we receive your reply.

When you reply, tell us where you entered the authorization code so we can find it and include the Account ID of your Apple Podcasts Connect account.

You can locate the Account ID on the Details pane in the Account section in Apple Podcasts Connect.

Example Account ID: 12a345bc6-d7ef-8901-2ghi-j3k4lm56n7o8

If you have additional questions related to this request, please reference case number 384791872432.

Best regards,

Mary Jane Apple Inc.

El feed que genera Castopod no tiene campo <verification />, pero como añadir campos a medida es sencillísimo, es la solución ideal porque nadie recibirá ese cambio de forma visible. Ve al panel de control de edición de tu podcast, y abajo de todo encontrarás un campo donde poder poner el campo extra:

Salva los cambios en tu podcast, verifica que en unos segundos, el feed tiene el mencionado campo dentro del objeto <channel />, y contesta a Apple con los datos que te han solicitado, que incluyen dónde pueden encontrar el valor en cuestión.

Good morning, Mary Jane.

Thanks for your prompt reply. As requested:My Podcasts Connect Account ID is 12a345bc6-d7ef-8901-2ghi-j3k4lm56n7o8.I’ve just included the code you provided in the tag of my feed, inside the <channel /> element:

<rss version=“2.0”> <channel> … ** <verification>381234</verification>** … </channel> </rss>

Thank you for your help and kind regards, ~Gabriel

Cuando recibas la confirmación y al cabo de un tiempo prudencial que te indicarán, deberías poder controlar tu relación con el directorio de Apple Podcasts tú mismo.

No tengas prisa en borrar cosas

En realidad ya está, pero es importante que no corras a Spotify y a tu feed a borrar cosas y deshacer cambios, porque puedes revertir el proceso sin querer.

1. Como comentaba en el apartado de la redirección permamente, no tengas demasiada prisa en borrar tu cuenta de Spotify, porque podrías perder oyentes.
2. Aún cuando ya tengas tu podcast en Apple Podcasts Connect, no corras a editar tu podcast en Castopod para retirar el campo de verificación. Ten en cuenta que el directorio de podcasts de Apple tienen páginas en todo el mundo, y no nos interesa que, por alguna razón, alguna versión antigua del feed se haya quedado en algún sitio y reasignen tu podcast a Spotify. Deja ese campo de verificación en tu feed el tiempo que te parezca oportuno.

Pues ya estaría

Hasta aquí mi experiencia. Espero que te resulte útil e interesante.

En lugar de escribir, me he dedicado a mover mi instancia personal de mastodon, este blog, y micromáquina, desde una Raspberry Pi 4B de 4GB a un Intel NUC. Ya tenía pensado mover todo a mi NAS utilizando Docker, pero finalmente decidí separar las cosas: en vez de seguir apilando Raspberrys, esta semana consolidé todo en una nueva máquina de mayor potencia pero consumo relativamente contenido.

Esta Raspberry Pi 4, de 4 GB, llevaba encendida dando servicio a mi instancia de Mastodon y a Micromáquina durante más de 1 año y medio, ininterrumpidamente.

La motivación principal para este movimiento ha sido la experiencia de Jacobo Vidal Pascual, del podcast Desde El Reloj, con una serie de fallos en su NAS.

Podéis escucharle aquí: “E0822: 32 horas sin NAS, sin Docker y sin página web”

Desde El Reloj @desdeelreloj@mas.to

Sigo con la web caída, disculpad las molestias… 😩

9:48 AM · abr. 9, 2024

El relato de los problemas causados por componentes moribundos, el precio de reemplazarlos y el riesgo que corrieron sus archivos personales, me dejaban claro el mensaje: tener varios servidores en mi NAS, constantemente accedidos por todos vosotros y por Activity Pub en el caso de Mastodon, elevaría el acceso a los discos a un ritmo fuera de mi control, reduciendo su vida útil. Los componentes de un NAS son *bastante *más caros que los componentes de un equipo tradicional, porque están pensados para evitar errores que no afectan el tipo de servicios que quiero alojar: para mi instancia de Mastodon y mis webs no necesito ni memoria ECC, ni discos en RAID; con una buena estrategia de copias de seguridad me basta. La perspectiva de poder llegar a ver todos mis datos en riesgo por el hecho de alojar webs públicas y los costes asociados no me hacían ninguna gracia.

Por otro lado, mi NAS es de Synology, lo cual tiene una serie de inconvenientes derivados de la licencia de su software y su política de soporte. No ya por cuestiones éticas de licencias del software y potencial enmierdificación futura a varios nieveles, sino también porque todo esto nos sujeta a políticas de soporte y fin de actualizaciones por las que podemos llegar a vernos obligados a renovar un equipo que, de otra manera, tendría una vida útil mucho mayor.

Así que nada: cuanto, antes mejor, y me puse manos a la obra.

Los beneficios de este cambio son varios:

• A corto plazo, el aprendizaje. Estoy aprendiendo un montón acerca de proxies inversos y de Docker, puesto que mover una instancia de Mastodon desde una máquina física a contenedores Docker, sin perder datos, no es trivial.
• A medio plazo tiene los beneficios ya comentados en el área de la vida útil del hardware donde tengo nuestros datos personales y los de la familia.
• A largo plazo, estos cambios transforman la forma de relacionarnos con internet y a través de internet, ya que nos devuelven un control que perdimos hace tiempo porque hacen de la tecnología algo mucho más personal.

Por el momento, ya se va notando una mejoría de rendimiento importante.