Entrevista de diseño de sistemas: ¿Cómo diseñarías un proxy MASQUE CONNECT-UDP?

Planteamiento y alcance

Un cliente móvil puede acceder de forma confiable a HTTPS, pero la voz, los juegos y las sondas en tiempo real dependen de UDP. Diseña un proxy que permita al cliente establecer un túnel HTTP hacia un host UDP de destino, cubriendo ciclo de vida, reenvío, autorización, límites de tasa, DNS, conmutación por error y fallback.

El RFC 9298 define CONNECT-UDP y una plantilla de proxy. El RFC 9297 define HTTP Datagrams y el Capsule Protocol para datos no confiables e información de control confiable, respectivamente. Una respuesta sólida separa la semántica del protocolo, los recursos del proxy y la política de seguridad; TLS por sí solo no previene el abuso.

Qué evalúa el entrevistador

• Distinguir el establecimiento, reenvío y cierre de túneles para CONNECT-UDP.
• Explicar el límite entre HTTP/3 Datagrams y Capsules, incluido el fallback.
• Diseñar listas de permitidos para destinos, políticas de puertos, autorización de usuarios y cuotas por tenant.
• Manejar DNS, tiempos de espera (timeouts), reintentos, sesiones semiabiertas y conmutación por error.
• Definir métricas de ancho de banda, concurrencia, pérdida, latencia, abuso y costo.
• Señalar que un proxy no puede agregar semántica de confiabilidad, ordenamiento o cifrado de extremo a extremo a UDP.

Preguntas para clarificar

1. ¿Tanto el cliente como el proxy admiten HTTP/3 Datagrams, o también debe funcionar HTTP/2?
2. ¿El destino es una red empresarial, medios en tiempo real o la Internet abierta? El modelo de riesgo difiere.
3. ¿El cliente proporciona un nombre de host y el proxy resuelve DNS? ¿Cuáles son los requisitos de privacidad y tiempo de vida?
4. ¿Cuántos túneles, bytes y flujos UDP concurrentes puede usar un tenant? ¿Se requiere enrutamiento regional?
5. ¿Cuáles son el período máximo de inactividad, el tamaño del paquete y la duración de la sesión?

Respuesta en 30 segundos

Restringiría el proxy a tenants autenticados y a un conjunto explícito de destinos, y luego establecería una sesión con CONNECT-UDP. Las Capsules transportan el control confiable; los HTTP/3 Datagrams transportan los datos UDP cuando son compatibles. De lo contrario, el proxy recurre a una encapsulación confiable o rechaza la solicitud, sin pretender una latencia equivalente. El plano de datos aplica cubos de tokens por tenant, límites de concurrencia y tiempos de espera por inactividad, mientras que un solucionador controlado vincula los resultados de DNS a la sesión. La conmutación por error reconstruye únicamente el estado que se puede reproducir. Validaría la latencia p99, la pérdida, el éxito del establecimiento, el uso de recursos, la tasa de rechazo y las alertas de abuso.

Diseño paso a paso

1. Sesión y máquina de estados

El cliente envía CONNECT-UDP para un host y puerto de destino. El proxy autentica la identidad, la política y la cuota, resuelve el destino y crea una sesión. Los estados deben incluir autorización pendiente, conectado, drenando y cerrado, cada uno con un tiempo de espera y un código de motivo para que las sesiones semiabiertas no retengan recursos indefinidamente.

CONNECT / .well-known/masque/udp/example.test/443 HTTP/3
Host: proxy.example

Una implementación debe seguir la plantilla de solicitud y las reglas de codificación del RFC 9298; el fragmento solo transmite la intención.

2. Separación de planos de control y de datos

El Capsule Protocol es adecuado para el control confiable de la sesión, los errores y las notificaciones de cierre. Los HTTP/3 Datagrams son adecuados para datos UDP que no requieren retransmisión. Asigna cada Datagram al socket UDP correspondiente y limita el tamaño del paquete, la profundidad de la cola y las ráfagas. Si la ruta carece de soporte para Datagram, elige explícitamente una encapsulación confiable o devuelve no admitido en lugar de ocultar el costo de latencia y CPU.

3. Autorización y política de destinos

Valida una credencial de corta duración, el estado del tenant y la vinculación del dispositivo antes de aplicar una lista de permitidos por nombre de host, rango de IP, puerto y propósito. Bloquea destinos de loopback, privados, de metadatos y de alto riesgo. Resuelve DNS con un solucionador controlado, registra la versión de resolución y el TTL, y evita que una nueva resolución cruce silenciosamente el límite de un tenant.

4. Límites, cuotas y costo

Limita los túneles, paquetes por segundo, tasa de bytes, duración de la sesión y tiempo de inactividad por tenant. Utiliza cubos de tokens tanto en el ingreso como en el egreso, con un umbral global de seguridad por nodo. Rastrea la CPU del proxy, los sockets del kernel, las colas, el ancho de banda de egreso y el costo por sesión; limitar solo el conteo de solicitudes HTTP no restringe un flujo UDP de larga duración.

5. Fallas y fallback

Registra motivos diferenciados para fallas de configuración, destinos inalcanzables, tiempos de espera de DNS y sobrecarga. Las nuevas sesiones pueden reintentar en un nodo en buen estado. En general, no es seguro reproducir los datos UDP ya enviados, por lo que la conmutación por error debe restaurar el estado de control o permitir que el protocolo superior establezca una nueva sesión. Si no se admiten Datagrams, elige una encapsulación confiable o una falla explícita y mide las rutas por separado.

6. Observabilidad y operaciones de seguridad

Para cada sesión registra tenant, nodo del proxy, versión de la política, motivo de establecimiento y cierre, bytes, paquetes, pérdida estimada, latencia p50/p95/p99 y eventos de limitación de tasa (throttling). Nunca registres credenciales completas ni cargas útiles confidenciales. Detecta escaneos de puertos, concentración de destinos, ráfagas de amplificación y contención entre tenants, con revocación rápida por tenant, destino o región.

7. Despliegue y aceptación

Realiza pruebas canary en regiones fijas y destinos en listas de permitidos, comparando las rutas directa, Datagram y de fallback. Aplica pruebas de estrés a pérdida, reordenamiento, reinicios del proxy, cambios de DNS, sesiones semiabiertas y exceso de tráfico. Los criterios de pase a producción deben incluir éxito de configuración, p99 en tiempo real, pérdida, recursos por sesión, falsos rechazos y latencia de alertas de abuso. Ajusta la política o deshabilita la ruta cuando se supere un umbral de seguridad o de recursos.

Ejemplo de respuesta sólida

Construiría un proxy autenticado limitado a un conjunto explícito de destinos. Tras CONNECT-UDP, valida credenciales, destino y cuota, resuelve DNS a través de un solucionador controlado y crea una sesión. Las Capsules transportan el control; los HTTP/3 Datagrams transportan datos UDP no reproducibles cuando están disponibles. Cada sesión tiene límites de tamaño de paquete, cola, tasa, inactividad y tiempo de vida.

La política de egreso bloquea puertos privados, de loopback, de metadatos y de alto riesgo, mientras que los cubos de tokens protegen ambas direcciones. Las nuevas sesiones pueden conmutar por error; los datos UDP enviados no se reproducen automáticamente. Observaría el éxito de configuración, latencia p99, pérdida, recursos, costo, escaneos y amplificación. Las pruebas canary comparan las rutas Datagram, de fallback y directa, con compuertas de seguridad y recursos capaces de deshabilitar la funcionalidad.

Errores comunes

• Decir “poner UDP dentro de HTTPS” sin semántica de túnel → separa CONNECT-UDP, Capsules y Datagrams.
• Tratar el proxy como un transporte confiable → la confiabilidad y el ordenamiento siguen siendo responsabilidad de la capa superior.
• Permitir destinos arbitrarios → utiliza listas de permitidos de hosts y puertos y bloquea rangos especiales.
• Limitar únicamente las solicitudes HTTP → limita también túneles, paquetes, bytes, tiempo de vida y tiempo de inactividad.
• Reproducir todos los datos UDP tras una falla → restaura únicamente el estado de control reproducible y permite que la capa superior se reconecte.
• Medir solo la latencia promedio → incluye métricas de p99, pérdida, rechazo, recursos y abuso.

Preguntas de seguimiento y respuestas

¿Qué sucede si HTTP/2 no puede transportar HTTP/3 Datagrams?

Elige una encapsulación confiable, un transporte tipo sondeo (polling) o un rechazo explícito según la carga de trabajo. Mide la latencia, la CPU y el ancho de banda por separado; no pretendas equivalencia con Datagrams no confiables.

¿Cómo previenes SSRF?

Verifica las IP resueltas después de DNS y antes de conectar, bloquea rangos de loopback, enlace local, privados, de metadatos y externos a la política, y gestiona el rebinding de DNS. Vincula la versión de la política a la sesión y hazla revocable.

¿Quién reintenta los paquetes UDP perdidos?

El proxy reporta observaciones del transporte, pero no reproduce paquetes de la aplicación. Un protocolo superior con semántica de idempotencia y secuencia decide los reintentos; los medios en tiempo real pueden descartar o reparar datos en su lugar.

¿Cómo recupera las sesiones el reinicio de un proxy?

Es preferible la reautenticación y una nueva sesión. Si el estado de control debe persistir, restaura únicamente el estado verificable y de corta duración sin datos no reproducibles, y drena los sockets antiguos de inmediato.

¿Cómo demuestras que los límites no causan falsos rechazos?

Compara el rechazo y el éxito por tenant, región, destino y versión del cliente. Establece un presupuesto de rechazos por error y reproduce ráfagas, sesiones largas y fallas de nodos para verificar el comportamiento de las cuotas.