Guía práctica para proteger un servidor dedicado ya en producción en OVH, Hetzner u otro proveedor sin migrar toda la infraestructura, usando GRE con o sin BGP.
Protección sin migración total
Es posible añadir una capa anti-DDoS sin reconstruir todo el entorno de producción.
Un túnel GRE suele ser más rápido de desplegar que una migración completa.
Solo túnel, GRE + BGP o IP protegidas: el mejor diseño depende de la arquitectura.
MTU, retorno del tráfico, routing y capacidad real del servidor deben validarse bien.
Muchas empresas, operadores gaming, plataformas SaaS y servicios expuestos a Internet ya ejecutan su infraestructura en servidores dedicados alojados en OVH, Hetzner o proveedores similares. Cuando empiezan los ataques DDoS, la primera idea que suele aparecer es: hay que migrarlo todo. En la práctica, no es la única opción ni siempre la mejor.
En muchos casos, un diseño anti-DDoS basado en GRE, con o sin BGP, permite proteger el servicio manteniendo el servidor donde ya está en producción. La cuestión no es solo cómo bloquear el ataque, sino cómo elegir un modelo de entrega realista, estable y utilizable en producción.
El escenario más común es claro: el cliente ya tiene un servidor dedicado en Hetzner, OVH o un proveedor similar. Los servicios están en producción, las IP ya se usan, existen copias de seguridad, monitorización y, a veces, otras máquinas dependen de ese entorno.
Cuando los ataques DDoS se vuelven recurrentes, el problema no es solo de la aplicación. El enlace puede saturarse antes de que la aplicación reaccione, la latencia sube, la experiencia de usuario empeora y una migración improvisada suele generar más riesgo que estabilidad.
Precisamente en este tipo de escenario tiene sentido una protección por GRE, con o sin BGP: se añade una capa de mitigación aguas arriba sin romper la producción existente.
Mover toda la infraestructura puede parecer lógico sobre el papel, pero la realidad de producción es distinta. El cliente suele necesitar conservar dependencias de red, hábitos operativos, scripts, licencias, flujos entre servidores e incluso restricciones comerciales o contractuales.
Por eso el objetivo racional no es moverlo todo por defecto. El objetivo es añadir protección eficaz sin crear un riesgo operativo innecesario.
Reconstruir toda una arquitectura en medio de ataques o inestabilidad rara vez es la mejor decisión.
El cliente mantiene sus servidores, procesos, almacenamiento, monitorización y dependencias locales.
Un túnel GRE bien integrado suele desplegarse más rápido que una migración completa de producción.
Es posible empezar protegiendo un servicio expuesto y ampliar después el perímetro.
Un túnel GRE encapsula el tráfico limpio entre la infraestructura de mitigación y el servidor dedicado o el router del cliente. El tráfico público llega primero a la capa anti-DDoS, se filtra y luego el tráfico legítimo vuelve a la máquina a través del túnel.
En este modelo, el servidor final sigue en OVH, Hetzner o donde ya esté alojado. Ya no recibe directamente el tráfico bruto de Internet: recibe tráfico después de la limpieza, lo que permite conservar el entorno existente y añadir una capa seria de protección de red.
Es especialmente útil para servicios ya en producción, workloads gaming, aplicaciones de negocio o infraestructuras que no pueden moverse de un día para otro.
Las IP protegidas o los prefijos anunciados aterrizan primero en la infraestructura anti-DDoS.
El objetivo es detener el tráfico malicioso antes de que alcance el entorno de producción.
El tráfico limpio se envía por GRE hacia el servidor dedicado o el router.
La aplicación permanece en su proveedor actual, pero detrás de una capa de mitigación dedicada.
El BGP es útil sobre todo cuando el cliente quiere anunciar sus propios prefijos IP, conservar el control del routing o integrar la protección en una arquitectura de red más avanzada. Es muy interesante para ciertos perfiles, pero no es obligatorio en todos los despliegues.
En muchos casos también podemos usar nuestras propias IP protegidas anti-DDoS y devolver el tráfico limpio al servidor dedicado de OVH o Hetzner a través del túnel GRE. En ese escenario, el cliente no necesita anunciar sus propios bloques para empezar.
En otras palabras, el BGP es una herramienta de flexibilidad arquitectónica. No es un requisito absoluto para proteger un servicio alojado en otra parte.
Ideal si ya dispone de ASN, de sus prefijos o si quiere un control más fino del routing.
Enfoque más simple cuando se busca proteger rápido sin añadir complejidad de routing.
El tráfico entra por IP protegidas y se entrega al servidor dedicado a través del túnel.
Se puede empezar simple y pasar más adelante a una arquitectura con BGP si el requisito cambia.
La elección correcta depende del nivel de control de red deseado, de la rapidez de despliegue y de si utiliza o no sus propios prefijos IP. No existe un único esquema válido para todos los clientes.
A menudo es la mejor opción para proteger rápido un dedicado ya en producción sin ASN ni anuncios BGP.
Más adecuado cuando el cliente posee sus IP, quiere mantener sus anuncios y necesita una arquitectura más flexible.
Muy útil para empezar rápido, validar latencia e integración y evitar una renumeración inmediata.
Relevante para entornos más grandes o clientes ya presentes en datacenter con necesidades de entrega directa.
Una buena protección no debe venderse como magia. Es importante entender qué resuelve realmente esta arquitectura y qué sigue requiriendo validación del lado del cliente.
El principal valor es conservar los servidores ya implantados en vez de imponer una migración completa.
Puede proteger primero un servicio y ampliar después el perímetro cuando el modelo esté validado.
Hay que revisar seriamente MTU, routing de retorno, firewall, políticas locales y capacidad real de la máquina.
Si la aplicación, el servidor o el diseño interno ya están saturados incluso sin ataques, la protección de red sola no bastará.
En Peeryx, la idea no es empujar una migración total por defecto. Primero observamos la infraestructura existente, el modo de entrega más coherente y el nivel real de control de red que hace falta.
Según el caso, eso puede significar IP protegidas entregadas por GRE al servidor dedicado, una arquitectura con BGP si el cliente quiere mantener sus anuncios o un despliegue progresivo centrado primero en los servicios más expuestos.
Imaginemos un cliente que ya aloja un servidor de juego o un backend de aplicación en Hetzner. Quiere conservar esa máquina porque todo su entorno ya está preparado, pero ataques recurrentes vuelven el servicio inestable y una migración completa no es deseable de inmediato.
El despliegue más limpio suele consistir en recibir el tráfico público en una capa anti-DDoS dedicada, filtrar el ataque y devolver únicamente el tráfico legítimo por GRE al servidor de Hetzner. Si el cliente posee sus propias IP o necesita más control de routing, se añade BGP. Si no, puede empezar desde el primer día con IP protegidas operadas del lado anti-DDoS.
Se revisan tipo de servicio, sensibilidad a la latencia, modo operativo y capacidad del servidor para recibir tráfico limpio.
Solo túnel, túnel + BGP o IP protegidas según el nivel de control deseado.
Se validan GRE, retorno del tráfico, MTU y estabilidad global antes del corte real.
El cliente conserva la infraestructura existente y gana una capa de mitigación alineada con el caso real.
La mayoría de los problemas no vienen del GRE o del BGP en sí mismos, sino de una mala definición inicial o de una arquitectura demasiado simplificada sobre el papel.
Sí. Es uno de los casos más habituales: el servidor sigue en Hetzner y recibe tráfico legítimo por GRE tras la mitigación aguas arriba.
No. El BGP es útil para algunos clientes, pero GRE con IP protegidas basta para muchos despliegues.
Sí. El principio es el mismo: el tráfico se limpia aguas arriba y se devuelve al servidor de OVH mediante una arquitectura adecuada.
Sí. A menudo es la vía más limpia: empezar simple, validar producción y añadir BGP más adelante si aporta valor.
Sí, precisamente porque añade protección sin imponer una migración completa desde el inicio.
Proteger un servidor dedicado de Hetzner u OVH frente a ataques DDoS no significa necesariamente migrarlo todo. En muchos casos, un diseño basado en GRE, con o sin BGP, permite añadir una capa seria de mitigación conservando el entorno ya existente.
El modelo correcto depende de la realidad técnica: necesidad de usar sus propias IP, deseo de conservar control del routing, búsqueda de un despliegue rápido o necesidad de empezar con IP protegidas ya operadas del lado de la mitigación.
El objetivo real no es solo parar el ataque, sino elegir una arquitectura creíble, limpia y viable en producción.
Cuéntenos su infraestructura actual, su proveedor de hosting, sus restricciones de red y el nivel de control que busca. Le diremos si conviene un GRE simple, GRE + BGP o entrega mediante IP protegidas.
