DDoS con VPN: ¿qué dirección queda realmente expuesta?
Un túnel oculta tu dirección de origen a un servicio, pero no tu enlace de subida, la salida de la VPN ni un puerto reenviado. Nombra el objetivo antes de planificar la mitigación.
Empieza por la petición que se supone que hará daño. Puede llegar a tu enlace doméstico, a la salida de la VPN o a una aplicación publicada detrás del túnel. Cada destino tiene un límite de capacidad distinto y un propietario distinto que puede filtrar el tráfico. Nombrar el objetivo es el primer paso útil, y una suscripción de VPN solo responde a uno de los tres.
Recorre la exposición antes del ataque
Sigue una petición entrante desde internet hasta el recurso que debe agotar. Si el destino es la dirección de tu casa, el límite es el enlace de acceso y el borde del proveedor. Si es la salida de la VPN, el límite pertenece al operador de la VPN. Si es un puerto reenviado, el propio manejo de la aplicación se convierte en el cuello de botella.
| Target | What saturates | Who can mitigate |
|---|---|---|
| Home connection address | The access link and provider edge | The access provider |
| VPN exit address | Provider capacity and filtering | The VPN operator |
| Published service | The application and its host | The service owner and hosting provider |
Los tres objetivos pueden atacarse juntos, pero se mitigan en lugares distintos. Anota cuál de ellos afirma tu plan que protege.
Tu propio enlace de subida conserva su dirección
Enrutar tu tráfico saliente por un túnel cambia lo que ven los servicios remotos. No elimina la dirección que tiene tu enlace de acceso ni desplaza la capacidad de ese enlace.
El tráfico dirigido al enlace sigue compitiendo con los propios paquetes del túnel. Un cortafuegos local puede descartar paquetes después de que lleguen, pero el enlace ascendente limitado ya los está transportando. Esa diferencia importa cuando el enlace está saturado, porque un filtro no puede devolver capacidad que nunca controló. Contacta con el proveedor de acceso a través de su proceso de incidentes si las pruebas apuntan a ese enlace.
La salida de la VPN es ahora una dependencia compartida
Cualquiera que observe la salida de la VPN puede enviar allí tráfico no deseado en su lugar. Que el proveedor lo absorba depende de la capacidad real, la arquitectura y cualquier servicio de mitigación que opere, no del cifrado del túnel.
Una salida compartida también puede sufrir un incidente dirigido a otro cliente o a la red del proveedor circundante. La guía de CISA sobre la denegación de servicio señala que cuando se ataca a un proveedor de internet o de nube, redes que nadie había elegido también pueden quedar a oscuras. Para un servidor autogestionado, el proveedor de alojamiento sigue siendo dueño de la capacidad ascendente que llega antes de que tu invitado vea un paquete. El filtrado dentro del invitado no puede recuperar el ancho de banda ya gastado.
Un puerto publicado necesita un plan de servicio
Un puerto reenviado expone deliberadamente una aplicación, así que las peticiones que parecen legítimas llegan a su ruta de gestión, se controle como se controle la admisión en el túnel. La admisión en el túnel, el filtrado en el host y la autorización de la aplicación cubren etapas distintas, y ninguna de ellas garantiza protección contra el agotamiento de recursos.
Usa los límites admitidos del servicio, la monitorización y la mitigación ascendente, y nombra quién puede pedir ayuda durante un incidente. Una suscripción de VPN de consumo no es prueba de que esos controles existan para tu aplicación.
Mantén el diagnóstico proporcionado. Las páginas lentas y las conexiones cortadas también vienen de mantenimiento, contención o fallos ordinarios, así que conserva marcas de tiempo y observaciones acotadas para el operador responsable. Nunca valides la afirmación con una inundación no autorizada y usa un plan aprobado con el propietario de la infraestructura.