Gluetun rompe la compatibilidad con PIA: actualizad a v3.41.3 urgentemente
El proxy VPN de contenedores pierde la conectividad con los servidores de Private Internet Access. Quienes fijen tags en Docker deben moverse a la versión patch para evitar caídas del tráfico.
Si tenéis el stack de homelab montado sobre contenedores y usáis Gluetun para enrutar el tráfico por VPN, probablemente os hayáis encontrado hoy con la pantalla en negro de Jellyfin o con Prowlarr incapaz de llegar a los indexers. El problema no es que Netflix haya endurecido los filtros ni que el router haya reiniciado por un fallo de memoria. Es Gluetun, y la solución es actualizar la imagen ahora mismo.
Quién administra sus servicios sabe que fijar la versión de las imágenes en Docker es una práctica sane, sobre todo cuando se depende de componentes externos que cambian frecuentemente. Pero esa disciplina tiene su precio cuando el upstream introduce una ruptura silenciosa. Los usuarios que anclaban a una versión previa de Gluetun han visto cómo su túnel se caía en bucle durante el fin de semana, dejando al aire servicios que asumen que hay conexión.
El desarrollador qmcgaw ha liberado la versión 3.41.3 como parche inmediato. Los logs del contenedor solían mostrar intentos de reconexión constantes sin éxito, a menudo sin un mensaje de error explícito que señalara la incompatibilidad del protocolo con los servidores actuales de Private Internet Access (PIA). La actualización restaura la capacidad de handshake y devuelve el tráfico a la red privada.
No es la primera vez que ocurre. El mismo proyecto pasó por algo similar hace unos meses, donde la versión 3.41.0 fue necesaria para mantener la conexión con PIA tras cambios en sus puertos o certificados. La estructura del mantenimiento de Gluetun es reactiva: se rompe algo por un lado y se parchea por el otro.
Para quien tenga Docker Compose y haya fijado la etiqueta v3.41.2 o anterior, el comando docker-compose pull seguido de un docker-compose up -d debería bastar. Si la infraestructura es más compleja o se usa Kubernetes, toca modificar el image tag en los despliegues y reiniciar los pods. No se trata de una vulnerabilidad de seguridad en el software, sino de una incompatibilidad operativa que deja los servicios anónimos sin anonimato y, lo que es peor, sin funcionamiento.
La actualización a la v3.41.3 es inmediata y no requiere cambios en los archivos de configuración YAML. Una vez conectado, conviene revisar que los servicios adyacentes que dependían del tunel hayan arrancado correctamente, ya que algunos pueden quedarse parados si la red virtual no estaba lista al iniciar el contenedor principal.