Pruebas de caos de red en Windows
Probar el caos significa romper algo a propósito, mientras miras, para descubrir qué hace tu software al respecto. En la capa de red eso es exactamente esta herramienta: una forma de inyectar un fallo en una aplicación y ver si sobrevive.
Los fallos que puedes inyectar
| Fallo | Qué modela |
|---|---|
| Pérdida, corrupción, duplicación | Un camino degradado. Los paquetes desaparecen, llegan dañados o llegan dos veces. |
| Latencia, jitter, picos | Un camino lento o inestable, incluida la parada de varios segundos que rompe los timeouts. |
| Restablecimientos de conexión | Un firewall o un balanceador de carga que mata conexiones en plena transferencia. |
| Caídas del enlace | El camino que desaparece y vuelve, en un ciclo. |
| Dirección o puerto bloqueado | Una dependencia inaccesible mientras todo lo demás funciona. |
| Sin internet, con la LAN viva | La forma del portal cautivo: lo local funciona, el mundo no. |
Lo que separa el caos del ruido: la repetibilidad
Un fallo aleatorio que no se puede reproducir produce una anécdota, no un informe de error. Cada decisión aleatoria aquí sale de una semilla, así que el mismo comando reproduce la misma ejecución: los mismos paquetes perdidos, el mismo jitter, en el mismo orden:
BeanNetworkTester.exe --loss 15 --rst-prob 5 --seed 42 --target myapp.exe --duration 120Esa es la diferencia entre «se cayó una vez el martes pasado» y una prueba que falla y que otra persona puede ejecutar.
En un pipeline
La línea de comandos informa mediante códigos de salida, así que una compilación puede distinguir «la aplicación falló» de «la herramienta no pudo arrancar», y la sesión termina sola: no hay ningún paso de limpieza que olvidar:
BeanNetworkTester.exe --loss 10 --rst-prob 5 --target myapp.exe --duration 90 --format json > chaos.ndjsonUna secuencia de fallos en lugar de uno solo es un archivo de escenario, y esos también son repetibles. Consulta escenarios temporales y pruebas de red en CI para ver los códigos de salida y el runner que necesita.
Hasta dónde llega el radio de impacto
Dos límites, y ambos son deliberados. El deterioro llega a un proceso, PID, dirección o puerto cuando apuntas, así que la máquina en la que trabajas sigue funcionando. Y es una sola máquina: esto es inyección de fallos para un cliente y su conexión, no para un clúster. Si buscas caos entre servicios y nodos, es otro tipo de herramienta, y esta es la pieza que rompe la red bajo una sola aplicación de Windows.
Todo es reversible al instante. STOP restaura la red, un límite de tiempo hace lo mismo, y un watchdog dentro de la herramienta apaga la captura si la herramienta misma muere: un fallo que inyectaste nunca debe sobrevivir a la ejecución que lo inyectó.