En esta página
Puntos clave
- No existe un único modelo universalEl mejor esquema depende de la propiedad de las IP, del routing y de las limitaciones de producción.
- GRE suele ser la vía más rápidaPara muchos clientes, un túnel simple ya es suficiente para empezar bien.
- BGP aporta controlTiene sentido cuando quieres conservar tus propios anuncios o una política de routing más avanzada.
- Las IP protegidas simplifican el inicioPermiten validar el servicio sin mover todo el entorno desde el primer día.
La decisión real: simplicidad, control o velocidad de puesta en marcha
El error más común es pedir la opción “más avanzada” sin revisar la necesidad real. Muchos clientes no necesitan BGP el primer día. Otros sí ganan valor manteniendo sus propios prefijos y su lógica de routing desde el inicio.
La elección correcta depende de tres puntos: quién posee las IP públicas, cuánto control de routing hace falta y con qué rapidez debe entrar en producción la protección.
Por qué el modelo de entrega cambia tanto el resultado
El modelo de entrega afecta al tiempo de despliegue, al esfuerzo de mantenimiento, al número de cambios sobre el entorno existente y a la facilidad para evolucionar después.
Una solución muy potente pero demasiado pesada de integrar puede frenar todo el proyecto. A la inversa, un modelo muy simple puede ser perfecto para un servicio aislado pero quedarse corto en una arquitectura multi-sitio o multi-prefijo.
- Impacto en producción
- Cuanto más complejo es el modelo, más hay que validar routing, tráfico de retorno, MTU y monitorización.
- Impacto en plazos
- GRE o IP protegidas suelen desplegarse antes que una integración BGP completa.
- Impacto en escalabilidad
- BGP gana mucho valor cuando hay varios servicios o varios bloques IP.
- Impacto comercial
- Un despliegue más simple reduce normalmente el tiempo entre el primer contacto y el go-live.
Cuándo elegir un túnel GRE simple
GRE solo suele ser la mejor respuesta cuando se quiere proteger rápido un servicio ya en producción y no hace falta anunciar prefijos propios.
Encaja muy bien con servidores dedicados, servicios web, API, plataformas de juegos e infraestructuras que quieren añadir anti-DDoS sin rediseñar toda la capa pública.
- Despliegue más simple
- Menos dependencias BGP en el lado del cliente
- Muy útil para probar rápido latencia e integración
- Buena opción para mantener un dedicado existente en OVH, Hetzner u otro host
Cuándo añadir BGP al túnel GRE
BGP se vuelve pertinente cuando tienes tus propias IP, tu ASN o una arquitectura donde el control del routing forma parte del requisito. Permite una gestión más limpia de los anuncios y más flexibilidad cuando el entorno crece.
No es una condición obligatoria para estar protegido. Es una decisión de arquitectura que aporta control cuando ese control tiene valor operativo real.
- Conservar tus prefijos
- El direccionamiento público y los anuncios siguen bajo tu control.
- Escalar mejor después
- El modelo encaja mejor cuando hay que gestionar varios servicios o varios bloques.
- Más trabajo inicial
- A cambio, la integración es más pesada que un GRE muy simple.
Cuándo usar IP protegidas anti-DDoS
Las IP protegidas suelen ser la forma más rápida de empezar. El tráfico entra primero por una IP expuesta en la infraestructura de mitigación y luego el tráfico limpio se entrega al servidor mediante túnel.
Este enfoque es especialmente útil si no quieres anunciar tus propios bloques, si quieres validar el servicio rápido o si primero buscas un modelo de producción sencillo antes de pasar a una arquitectura más avanzada.
El servicio se publica en una IP protegida
El punto de exposición público se sitúa en la capa de mitigación.
El tráfico malicioso se filtra aguas arriba
La idea es detener el ataque antes de la entrega a tu entorno.
El tráfico legítimo se entrega a tu infraestructura
La entrega puede hacerse por GRE u otro método según el diseño.
Queda margen para evolucionar
Si el contexto cambia, la arquitectura puede pasar después a más control de routing.
Cómo decidir rápido entre los tres modelos
Si quieres ir rápido, proteger un servicio concreto y evitar complejidad, lo normal es empezar por GRE simple o por IP protegidas. Si conservar tu espacio público es importante desde el principio, GRE + BGP tiene sentido.
El mejor diseño suele ser el que protege rápido sin encerrar la arquitectura en complejidad inútil. El objetivo no es impresionar sobre el papel, sino seguir siendo limpio, estable y explotable.
- Quieres velocidad
- GRE simple o IP protegidas.
- Quieres mantener tus IP
- GRE + BGP.
- Quieres probar antes de ir más lejos
- IP protegidas + túnel.
- Gestionas varios servicios y routing avanzado
- BGP suele ser el modelo más coherente.
Errores frecuentes a evitar
El error más habitual es elegir un modelo demasiado pesado para la necesidad real, o demasiado simple para un entorno ya complejo. También es arriesgado ignorar el tráfico de retorno, el MTU y la forma exacta en que el servicio se publicará.
¿Es obligatorio BGP para estar protegido?
No. Muchos servicios se pueden proteger correctamente con GRE y, cuando conviene, con IP protegidas.
¿Un túnel solo basta para un servidor dedicado?
En muchos casos sí, sobre todo cuando lo principal es proteger un servicio que ya está en producción.
¿Cuándo son más útiles las IP protegidas?
Cuando quieres entrar en producción rápido, reducir complejidad y evitar anunciar tus propios bloques al inicio.
¿Se puede empezar simple y evolucionar luego?
Sí. Muy a menudo es la mejor estrategia: validar el servicio primero y hacer evolucionar el diseño sólo si la arquitectura lo requiere.
