En esta página
Puntos clave
- Dibujar ambos sentidosLa entrada, la entrega filtrada y el retorno de la aplicación pueden tener restricciones diferentes.
- Separar observación y filtradoUn colector de flujos mide tráfico; otro componente debe aplicar las decisiones a los paquetes.
- Incluir mantenimiento y fallosUn segundo nodo solo resulta útil si el enrutamiento, la capacidad y los procedimientos permiten el respaldo previsto.
Empezar por la ruta que realmente sigue el tráfico
Un diseño DDoS útil comienza por los destinos protegidos, sus rutas aguas arriba y el primer recurso que puede agotarse. Dibuje la entrada normal, la ruta durante la mitigación y el retorno. Marque cada entrega limitada e identifique quién puede anunciar, desviar o retirar cada prefijo.
El diseño debe explicar qué ocurre con una solicitud legítima desde su llegada hasta la respuesta. Un diagrama que termina en una nube de scrubbing omite el enlace receptor, túnel, firewall y servidor que aún deben manejar el tráfico residual.
Distinguir cuatro responsabilidades
Estas funciones pueden compartir producto, pero requieren pruebas separadas. Ver una ruta en BGP no demuestra por sí solo que un filtro aplique la regla deseada. Recibir telemetría de flujos no implica que el colector esté en la ruta de los paquetes.
| Función | Resultado o acción | Prueba de aceptación |
|---|---|---|
| Observar y detectar | Muestras, contadores, alertas o posible incidente. | Punto de observación, muestreo, demora y comportamiento sin datos conocidos. |
| Decidir y dirigir | Cambio autorizado de ruta o política. | Alcance, validación, convergencia y procedimiento de retirada. |
| Inspeccionar y filtrar | Reenvío, descarte o limitación de paquetes compatible. | Política instalada, contadores de decisión y servicio legítimo correcto. |
| Entregar y servir | El tráfico filtrado llega a la aplicación y las respuestas regresan. | Capacidad, MTU, rutas, latencia y comprobaciones de aplicación. |
Elegir la ubicación según el cuello de botella
La mitigación aguas arriba es pertinente si la carga ofrecida puede agotar el acceso del cliente. El filtrado local sirve a operadores con suficiente capacidad entrante que desean controlar las decisiones en sus equipos. Un diseño híbrido puede combinar ambos, pero añade interacciones de políticas y fallos que necesitan un responsable.
Un proxy de aplicación puede encajar con un protocolo y modelo de entrega compatibles. No es intercambiable con la protección de cualquier prefijo enrutado. Tampoco un control HTTP cubre todos los servicios UDP o TCP. Enumere aplicaciones y familias de direcciones en vez de tratar Layer 7 como una capacidad universal.
La protección permanente y bajo demanda requieren pruebas distintas
En un diseño permanente, el tráfico normal utiliza continuamente la ruta protegida. Valide latencia habitual, retorno, mantenimiento y capacidad. Bajo demanda, mida además las demoras de detección, decisión y cambio de ruta; la transición puede afectar sesiones aunque la ruta final funcione.
Use histéresis y un procedimiento explícito de recuperación para evitar activaciones y retiradas repetidas alrededor de un umbral. La telemetría ausente o caducada necesita una respuesta definida. El operador debe saber si la ruta permanece, se retira o requiere intervención; los controladores no se comportan todos igual.
Peeryx Flow Collector observa fuera de la ruta y coordina desvíos; no filtra paquetes en línea. Su desvío automático se limita a prefijos IPv4 /24 autorizados. Hay que verificar por separado elegibilidad, permisos de enrutamiento y servicio protegido; esto no implica desvío automático IPv6.
Ejemplo: reducción aguas arriba con reglas locales
Supongamos un operador con una entrega de recepción de 10 Gbit/s y aplicaciones tras un firewall local. Si el tráfico entrante supera esa entrega, añadir un filtro más potente detrás no desplaza el punto de pérdida. Una ruta protegida aguas arriba puede abordar esa limitación mientras la capa local mantiene la política de acceso.
Si la entrega usa GRE, documente la ruta exterior, la MTU interior efectiva y las rutas de retorno. Pruebe transferencias suficientemente grandes para revelar problemas de MTU; un ping pequeño no basta. Los controles con estado pueden exigir un camino compatible en ambos sentidos. Es un ejemplo de diseño, no una promesa de desvío sin interrupciones.
Hacer verificable la entrega
Demostrar autorización y conectividad
Confirme propiedad o autorización de prefijos, anuncios aceptados, siguientes saltos y cada familia requerida. Compruebe rutas normal y protegida desde puntos independientes.
Calificar la capacidad durante un fallo
Mida la mezcla de tráfico con las funciones previstas. Considere reparto desigual, enlaces receptores y pérdida del nodo o uplink que el diseño afirma tolerar.
Probar la aplicación
Pruebe sesiones nuevas y existentes, protocolos relevantes, transferencias sensibles a MTU y retorno. Observe operaciones legítimas junto con los contadores de mitigación.
Ensayar la recuperación
En un entorno aislado o mantenimiento acordado, pruebe el fallo previsto de proceso, enlace o nodo. Registre convergencia, impacto en sesiones, reversión y acceso administrativo.
La etiqueta backup no demuestra una conmutación
- Dos túneles en el mismo router físico no aportan independencia frente a su fallo.
- Una sesión BGP de respaldo establecida no demuestra que se seleccionen rutas útiles y reenvío correcto cuando desaparezca la principal.
- Un bypass puede mantener conectividad saltándose el filtro; compruebe la protección resultante.
- Dos enlaces de igual velocidad no garantizan reparto uniforme ni duplican la capacidad de un flujo individual.
- Una conmutación que funciona con paquetes sin estado puede interrumpir sesiones dependientes de estado compartido.
Mantener un registro operativo breve
El registro de entrega debe contener topología, alcance protegido, supuestos de capacidad, resultados de aceptación, responsables de alertas y reversión. Separe comportamiento previsto de resultados observados. Repita las pruebas pertinentes tras cambios de rutas, software o camino físico.
Preguntas y respuestas
¿Un colector filtra el tráfico que muestra?
No necesariamente. La telemetría puede exportarse a un observador fuera de la ruta de reenvío. Identifique el componente separado que realmente inspecciona o descarta paquetes.
¿Un segundo túnel garantiza redundancia de routers?
No. Compruebe equipos físicos, rutas subyacentes, rutas seleccionadas y el fallo probado. Dos túneles pueden compartir el mismo punto de fallo.
¿Un ping correcto valida todo el diseño?
No. Solo confirma una prueba limitada de conectividad. Valide tamaños relevantes, aplicaciones, carga, retorno y procedimiento de fallo previsto.
