Enrutado
Proxifier (driver de filtrado a nivel de kernel) enruta por PID. Un manager observa los procesos, los agrupa en buckets y regenera el perfil cuando cambia la topología.
Proyecto 02 · infraestructura / observabilidaden operación
Sala de control
Enrutado por proceso, failover automático y detección de instancias congeladas.
Orquestador de red por proceso para Windows: asigna cada instancia de una aplicación a una salida de red distinta (proxy o ISP local), hace failover automático cuando una salida cae, detecta instancias congeladas por imagen y se despliega solo desde git. Todo en PowerShell 5.1, sin inyectar código en la aplicación que administra.
Instancias
32
techo de diseño · 23 a 26 en operación
Salidas de red
7
6 proxies + ISP · 8 por bucket
Código inyectado
0
enrutado a nivel de kernel
Fallas para marcar caído
2
anti-parpadeo
Ciclo de despliegue
≤10 min
con reversión automática
Líneas de PowerShell
~3,000
6 piezas · 1 archivo de config
Fig. 1 · Demo animada · datos simulados, modelo real
Siete pasos en bucle: operación, caída, failover, reparación, retorno, congelamiento, reinicio
1/7
0
0
0
0
Cada sala es un bucket, cada pantalla una instancia. La franja superior muestra números reales que el equipo empuja a esta Pi cuando está en línea.
Fig. 2 · El problema
Mismo ejecutable, 32 veces, cada uno por una IP distinta. Y no se puede tocar la aplicación.
Cada instancia debe salir a internet por la misma salida siempre, aunque el proceso se reinicie. Si un proxy cae, sus instancias tienen que seguir funcionando sin intervención humana y volver solas cuando se recupere. El equipo se administra por escritorio remoto y a veces se reinicia solo por Windows Update, así que todo debe recuperarse sin nadie conectado.
Fig. 3 · Restricciones que hacen interesante el problema
- 01No se puede inyectar código en la aplicación por su sistema anti-manipulación. Descarta proxificar por DLL.kernel
- 02Todas las instancias son el mismo ejecutable. Las herramientas que enrutan por nombre de programa no sirven.por PID
- 03PowerShell 5.1, no 7: sin ternario, try/catch que el parser acepta y el runtime rechaza, locale que corrompe bytes no ASCII.ASCII puro
- 04El equipo se reinicia solo. Nada puede depender de que haya alguien conectado.autónomo
La asignación instancia → bucket se persiste en un ledger por número de ventana, que sobrevive a los reinicios del proceso. El PID no.
Fig. 4 · Cómo está resuelto
Anti-fuga
Modo estricto: todo lo que no tiene regla se bloquea. Más una regla de firewall contra QUIC (UDP 443), por donde el navegador se fuga con la IP real.
Failover
Un vigilante marca un proxy caído tras dos fallas seguidas. Sus instancias se redistribuyen entre los sanos, nunca hacia el ISP. El ledger no cambia, así que al recuperarse vuelven solas.
Detección de congelamiento
Captura cada ventana desde el compositor de Windows, no desde la aplicación, y compara huellas de 64×36 en gris. Un cliente 3D vivo nunca produce dos cuadros idénticos; uno congelado sí.
Despliegue
El equipo sigue una rama deploy. Cada 10 minutos hace fetch; si hay commit nuevo detiene, resetea, verifica que todo sea ASCII y parsee, y arranca. Si falla, revierte al commit anterior.
Observabilidad
Dashboard servido por el propio stack: instancias con bucket e IP de salida, ocupación, failover en curso, latencia de proxies 24 h. Lee JSON escritos de forma atómica.