🛡️ Cortafuegos de nivel de red personalizable de Trooper.AI

Flujo de Tráfico

Su servidor de GPU opera detrás de nuestra infraestructura de red NAT y capa de seguridad de red, lo que significa que todo el tráfico pasa primero por el cortafuegos de red de Trooper.AI antes de llegar al servidor.

El tráfico UDP está bloqueado por defecto, pero puede habilitarse mediante la configuración del cortafuegos si es necesario.

Esta arquitectura le permite gestionar la seguridad de red de manera centralizada mientras se enfoca exclusivamente en construir y ejecutar sus cargas de trabajo de IA.

Cómo usar el cortafuegos integrado de nivel de red

La interfaz de cortafuegos de Trooper.AI ofrece un cortafuegos nativo ubicado directamente frente a tu servidor con GPU. Esto te permite controlar el tráfico de red antes de que los paquetes lleguen al sistema operativo del servidor con GPU. También puedes limitar el tráfico saliente si lo deseas por razones de seguridad o rendimiento.

Esta capa de seguridad está completamente integrada en la infraestructura de Trooper.AI y puede accederse mediante Acciones > "Reglas del Firewall".

La interfaz funciona de la siguiente manera:

• (1) Tabla de reglas – Muestra todas las reglas de firewall configuradas. Las reglas pueden ordenarse (sorting capability: clasificarse), editarse o eliminarse.
• (2) Rutas predeterminadas – Define el comportamiento por defecto para el tráfico que no coincide con ninguna regla.
• (3) Editor de reglas – Agregar nuevas reglas basadas en rangos de puertos, rangos de IPs y acción (Permitir / Negar)

Este diseño le permite controlar la exposición en red de su servidor con GPU sin modificar la configuración del sistema operativo.

Filtro de salida

El cortafuegos de nivel de red de Trooper.AI aplica un control granulado sobre el tráfico de red saliente originado desde su servidor GPU Blib. Esta funcionalidad permite que las organizaciones implementen medidas estrictas de cumplimiento normativo, optimicen la utilización del ancho de banda y mejoren la seguridad operativa.

Nota: Las reglas de salida pueden bloquear o limitar las descargas de paquetes y modelos (apt, pip, Hugging Face). Si experimenta problemas de conexión, revise primero sus reglas del cortafuegos.

La interfaz funciona de la siguiente manera:

• (1) Tabla de reglas – Muestra todas las reglas configuradas del cortafuegos saliente. Las reglas pueden ordenarse, editarse o eliminarse.
• (2) Rutas predeterminadas – El tráfico saliente siempre está permitido por defecto.
• (3) Editor de reglas – Agregar nuevas reglas basadas en rangos de puertos, rangos de IPs y acción (Permitir/Negar). Para una regla de Permitir puede establecer un límite de velocidad hasta un máximo de 50 Mbit/s.

La implementación del cortafuegos mantiene una separación total entre el entorno de aplicación de políticas y los entornos de ejecución del servidor:

• Todo el filtrado se realiza en la capa de infraestructura de red antes de la transmisión del paquete
• Los procesos de aplicación carecen de visibilidad o capacidad para modificar las configuraciones del cortafuegos
• Protección contra posibles compromisos de componentes del lado servidor que intenten eludir restricciones

Configuraciones predeterminadas del cortafuegos

Para simplificar la seguridad de salida (outbound), Trooper.AI ofrece dos plantillas predefinidas que recomendamos para uso general. Puede aplicar cualquiera automáticamente al pedir un nuevo servidor GPU Blib: simplemente elíjala en el diálogo de pedido y se configurará nada más arrancar el servidor, sin necesidad de crear reglas manualmente. ¿Prefiere decidir después? Pida con «Sin plantilla» y luego reeemplace cualquier plantilla usted mismo/a cuando lo desee desde el panel.

Ambos perfiles solo moldean el tráfico saliente (desde su servidor → internet). Su rango de puertos públicos entrantes y SSH permanecen abiertos por defecto, y las reglas se evalúan de arriba hacia abajo — gana la primera regla que coincida

• 🟢 Equilibrado — nuestra recomendación predeterminada para casi todos: permanece completamente abierto para el trabajo de IA habitual mientras bloquea silenciosamente el spam/conocido/gusanos/abuso de botnets.
• 🔴 Estricto — una lista de permisos bloqueada (allow-list) para cajas de inferencia pura que solo requieren lo esencial.

Aplicar al hacer el pedido o reconstruirlo más tarde usted mismo: seleccione una plantilla en el diálogo de pedido para que se aplique automáticamente, o recréelo cuando sea necesario bajo Administrar → su servidor → 🛡️ Cortafuegos → Saliente utilizando las tablas a continuación.

Protección siempre activa (todos los ajustes predefinidos, incluyendo «Sin ajuste predeterminado»): mitigación multicapa contra ataques DDoS, límites de conexión/inundación por IP, aislamiento de inquilinos y protección de salida para redes privadas (RFC1918) se aplican automáticamente y no pueden desactivarse.

🟢 Equilibrado (Recomendado)

Todo permanece abierto para el trabajo habitual de IA — apt, pip/uv, Hugging Face, Docker, bases de datos y tus propias APIs — mientras un conjunto de bloqueos basados en las mejores prácticas industriales evita el spam, gusanos y abuso por botnets. El tráfico saliente UDP está desactivado por defecto, excepto para DNS y sincronización horaria.

Efecto neto: todo el tráfico saliente TCP permanece abierto excepto en los puertos de abuso listados; el tráfico saliente UDP está limitado al DNS (53) y NTP (123). QUIC/HTTP-3 recae automáticamente en TCP 443, por lo que las descargas no se ven afectadas. ICMP (ping/detección de MTU del camino) sigue permitido.

🔴 Estricto (Avanzado)

Solo lo esencial sale — ideal para cajas de inferencia/IA puras. Todo lo que no esté en la lista de permisos (allow-list) es bloqueado (negación por defecto).

Efecto neto: apt, pip/uv, git (HTTPS y SSH), las descargas de Hugging Face y los pulls de Docker funcionan correctamente; cualquier tráfico en puertos no estándar queda bloqueado. Se permite el ICMP. Funciona mejor cuando tus aplicaciones solo usan puertos estándar.

🔒 Bloqueo de IP para SSH (opcional)

Si se activa al momento del pedido, se añaden dos reglas entrantes para que solo tu IP pueda acceder a SSH, mientras los puertos públicos de tus aplicaciones permanecen abiertos para todos:

Si cambia tu dirección IP, actualiza solo la fuente en Administrar → Cortafuegos → Entrante.

¿Cómo verificar o reconstruir

• Verificar: abre Administrar → tu servidor → 🛡️ Cortafuegos → Saliente. La insignia de conteo en la pestaña muestra cuántas reglas están activas; compáralas con la tabla anterior.
• Reconstruir en una máquina existente: en la pestaña Saliente, agrega una regla por fila en el mismo orden (arriba = mayor prioridad), luego haz clic en Aplicar ahora
• Hazlo después: puedes empezar con Sin configuración predeterminada y agregar estas reglas cuando quieras — los cambios surten efecto tras hacer clic en Aplicar ahora

Las reglas se evalúan de arriba hacia abajo; la primera coincidencia tiene prioridad. Mantenga las dos reglas Permitir para DNS/NTP por encima de cualquier regla genérica Denegar, ya que, de lo contrario, fallarán la resolución de nombres y la sincronización horaria.

Solución de problemas

Revise estos pasos si no puede acceder a sus servicios en el servidor de GPU después de realizar algún cambio en el Firewall o la pila de red. Si aún no logra acceder a su máquina, verifique primero los ajustes del cortafuegos y luego contáctenos: Contacto de Soporte

IMPORTANTE: Deshabilitar cualquier cortafuegos local (si se activó accidentalmente)

Si un cortafuegos local como UFW estaba habilitado en el servidor y está causando problemas de conectividad, puede deshabilitarse con:

sudo ufw disable

Salida:

Firewall stopped and disabled on system startup

Luego desactive el servicio:

sudo systemctl disable ufw

Salida:

Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ufw
Removed /etc/systemd/system/multi-user.target.wants/ufw.service.

Debe eliminar por completo cualquier Firewall local en su servidor de GPU. ¡Esto le facilitará la vida!

Solución de problemas: ¿Por qué mis reglas del cortafuegos no funcionan como se espera?

Las reglas del cortafuegos se evalúan de arriba hacia abajo

La primera regla que coincida con el tráfico se aplica, y ninguna otra regla es verificada.

Ejemplo de orden incorrecto:

1  Deny  0.0.0.0/0      Port 14141
2  Allow 78.168.0.0/16  Port 14141

En este caso, la regla 1 bloquea todo el tráfico SSH antes de que se alcance la regla 2.

Orden correcta:

1  Allow 78.168.0.0/16  Port 14141
2  Deny  0.0.0.0/0      Port 14141

Siempre coloque las reglas de permiso más específicas por encima de las reglas generales de denegación

Solución de problemas: ¿Por qué mi regla del cortafuegos no coincide con mi dirección IP?

Las reglas del cortafuegos utilizan rangos CIDR para definir direcciones IP permitidas o bloqueadas.

Asegúrate de que el rango incluya efectivamente tu dirección IP.

Ejemplos:

Si el rango CIDR es incorrecto, la regla del cortafuegos nunca coincidirá con tu conexión.

Solución de problemas: ¿Por qué sigue bloqueado mi puerto?

Verifica que el puerto correcto esté permitido en el cortafuegos. Puedes encontrar los puertos correctos en el panel de gestión de tu Blib. Si se permite un puerto equivocado en el cortafuegos, el tráfico nunca llegará a tu servidor con GPU.

Solución de problemas: Comprensión del control de tráfico saliente o ¿Por qué una conexión saliente sigue funcionando?

El tráfico saliente en el cortafuegos de Trooper.AI se refiere exclusivamente a conexiones de red iniciadas activamente por tu servidor GPU Blib. Esta distinción aclara que:

• «Saliente» = Conexiones donde tu servidor actúa como cliente (iniciando la comunicación).
• «Tráfico de retorno» = Respuestas a conexiones entrantes previamente establecidas (donde los sistemas externos actúan como clientes).
• Puede restringir el tráfico SSH saliente mientras mantiene acceso SSH entrante para conexiones remotas.
• Las restricciones de tráfico saliente se aplican por igual en todos los protocolos—incluyendo HTTP. Incluso si configuras DENIEGA para todos los puertos salientes, servicios basados en HTTP como WebProxy, Jupyter y OpenWebUI seguirán funcionando porque sus conexiones provienen externamente, lo que significa que dependen del tráfico entrante

Nota importante: Una conexión entrante explícitamente permitida puede generar tráfico de retorno legítimo para mantener la continuidad de sesión; esto no se ve afectado por las reglas salientes, salvo que esté expresamente restringido.

Todas las políticas de salida se aplican únicamente a conexiones originadas internamente por su instancia del servidor GPU.

Solución de problemas: ¿Por qué APT/PIP u otras tareas del sistema ya no funcionan?

🚨 Asegúrese de que sus reglas del cortafuegos salientes permitan el acceso necesario a la red para los gestores de paquetes (pip, apt-get) y actualizadores del sistema para recuperar parches críticos y actualizaciones del SO de manera segura. Verifique que los repositorios estándar y servidores de actualización estén en una lista blanca para resolver dependencias sin problemas y realizar operaciones de mantenimiento.

Solución de problemas: ¿Por qué está bloqueada mi interfaz web?

El cortafuegos de Trooper.AI controla todos los puertos entrantes y salientes, incluyendo aquellos utilizados por las interfaces web.

Si el puerto utilizado por servicios como:

• OpenWebUI
• Cuaderno de Jupyter
• paneles internos
• herramientas de IA personalizadas

está bloqueado en el cortafuegos, la interfaz web también será inalcanzable

Una configuración segura común es restringir el acceso al rango de IPs de la empresa.

Ejemplo:

Allow 203.0.113.0/24  Port 14511
Deny  0.0.0.0/0       Port 14511

Esto permite solo a los usuarios de su organización acceder a la interfaz web segura.

Solución de problemas: ¿Por qué no es accesible el acceso por SSH?

Si el acceso por SSH falla, verifique lo siguiente:

1. No instale un cortafuegos UFW local que bloquee el puerto interno de SSH 22
2. Su dirección de IP debe estar dentro del rango CIDR permitido
3. La regla de permitir con el puerto público SSH (algo como 14511 – no es el 22, que es el puerto interno) debe aparecer por encima de cualquier regla de denegar

Además, verifica la configuración de Permitir SSH al final de la tabla de configuración del cortafuegos.

Si el SSH está deshabilitado al final de la configuración del cortafuegos, el servidor solo aceptará conexiones SSH desde direcciones IP permitidas por las reglas anteriores.

Solución de problemas: ¿Por qué sigue bloqueándose el tráfico si ya agregué una regla?

El tráfico que no coincida con ninguna regla seguirá las Rutas Predeterminadas definidas en la configuración del cortafuegos.

Si una regla no coincide exactamente (rango de IP incorrecto, puerto equivocado o orden erróneo), el tráfico puede ser derivado al regla de denegación por defecto.

Siempre verifique:

• orden de las reglas – gana la primera coincidencia (de arriba hacia abajo)
• rango CIDR – ver ejemplos
• número de puerto - visible en el panel de gestión
• comportamiento de ruta predeterminada

Verificación final: Intente hacer clic en PERMITIR TODO y verifique si funciona. Si es así, hay una regla anterior que no coincide correctamente.