Proxylity abrió endpoints de WireGuard a dispositivos desconocidos en AWS

Why it matters

Proxylity is separating encrypted connectivity from device identity, letting developers onboard unknown WireGuard clients and trigger durable AWS workflows without running UDP servers.

El 3 de junio, el fundador de Proxylity, Lee Harding agregó dos capacidades al UDP Gateway de Proxylity: endpoints WireGuard que aceptan clientes sin registro previo, y entrega asíncrona desde esos endpoints hacia AWS Lambda. La actualización del producto ofrece a los desarrolladores una forma de recibir paquetes cifrados de dispositivos recién aprovisionados y usar cada paquete para iniciar un flujo de trabajo serverless de larga duración.

El lanzamiento es una extensión directa de la carrera de Harding gestionando la infraestructura que ahora intenta eliminar. Según la página About de Proxylity, él operó una plataforma global de Wi‑Fi en Eleven Software que atendía a 9 millones de usuarios diarios y procesaba más de 10,000 transacciones RADIUS-over-UDP por segundo. Anteriormente, construyó sistemas serverless en Zapproved usando Lambda, S3, SQS y SNS, después de pasar más de una década desarrollando sistemas C++ sensibles al rendimiento en Autodesk.

Esos trabajos pusieron en evidencia la descoincidencia detrás de Proxylity: AWS facilitó relativamente la conexión de solicitudes HTTP a cómputo y almacenamiento gestionados, mientras que las aplicaciones UDP seguían dejando a los equipos de ingeniería la responsabilidad de servidores, balanceadores de carga, planificación de capacidad y gestión de parches. Harding fundó la compañía en Portland, Oregon en 2024 para hacer que el tráfico UDP se comporte como otra fuente de eventos serverless.

De pares fijos a inscripción pública

Los WireGuard Listeners de Proxylity anteriormente requerían que los clientes enumeraran la clave pública de cada peer permitido en una plantilla de CloudFormation. Ese enfoque funciona para un conjunto controlado de máquinas. Se convierte en un cuello de botella de despliegue cuando una aplicación móvil genera un par de claves durante la instalación, o cuando los dispositivos crean claves en el primer arranque.

La nueva propiedad AllowUnknownPeers cambia ese modelo de inscripción. Cuando está habilitada, el WireGuard Listener de Proxylity completa un handshake con un cliente válido incluso cuando la clave pública del cliente está ausente de la lista de peers configurada. WireGuard sigue cifrando la conexión, pero Proxylity ya no considera el registro previo como un requisito.

Harding escribió en el anuncio de lanzamiento: "La analogía con HTTPS es intencional." Un servidor web público puede establecer una conexión TLS cifrada antes de conocer la identidad del visitante. Proxylity está aplicando esa separación a WireGuard: el cifrado ocurre en el límite de red, mientras que la función Lambda o el flujo de trabajo aguas abajo se encargan de la identidad y la autorización.

Esa distinción importa. El cifrado por sí solo no establece que un dispositivo deba recibir acceso. Proxylity ofrece una opción UnknownPeerPreSharedKey para despliegues que necesitan una puerta básica. Todo cliente desconocido debe poseer la misma clave precompartida, mientras que los peers nombrados pueden continuar usando secretos individuales en el mismo Listener.

Harding describe la clave compartida con precisión como una barrera más que como una identidad fuerte. Una credencial filtrada podría admitir a cualquier poseedor, y rotarla a lo largo de una flota grande crea su propio trabajo operativo. Las aplicaciones que atienden dispositivos sensibles todavía necesitan autenticación por dispositivo, registros de inscripción y revocación de credenciales en la capa de aplicación.

Un paquete UDP se convierte en un disparador de flujo de trabajo

La segunda característica cambia lo que ocurre después de que Proxylity recibe un paquete. La integración de Lambda del UDP Gateway había utilizado invocación sincrónica RequestResponse, dejando al gateway esperando a que la función terminara y usando su valor de retorno para enviar paquetes de vuelta al cliente.

Configurar UseAsyncInvoke cambia la entrega al modo de invocación Event de Lambda. La documentación de AWS indica que una invocación asíncrona encola el evento y devuelve un estado 202 sin esperar la respuesta de la función. En la implementación de Proxylity, el gateway puede continuar inmediatamente, el valor de retorno de la función se descarta y el cliente UDP originario no recibe respuesta.

Eso hace que el modo sea adecuado para cargas de trabajo tipo fire-and-forget. Un paquete entrante puede iniciar una máquina de estado de Step Functions o una función durable de AWS Lambda, que AWS diseñó para crear puntos de control y soportar ejecuciones que duren hasta un año.

El ejemplo de Proxylity es el aprovisionamiento de dispositivos. Un dispositivo genera un par de claves WireGuard en el primer arranque, se conecta usando una clave precompartida para toda la flota y envía un paquete de aprovisionamiento. Lambda entonces inicia un flujo de trabajo que registra la identidad, emite un certificado, crea un registro en DynamoDB y envía una notificación. La confirmación llega al dispositivo por otro canal después de que el flujo de trabajo se complete.

La invocación asíncrona también cambia el modelo de fallos. El anuncio de lanzamiento advierte que AWS puede reintentar invocaciones asíncronas fallidas, por lo que los manejadores y los flujos de trabajo aguas abajo deberían ser idempotentes o usar una cola de mensajes no entregados (dead-letter queue). Proxylity también evita que UseAsyncInvoke y el streaming de respuesta se habiliten en el mismo destino porque los dos modos hacen promesas opuestas: uno abandona la ruta de respuesta, mientras que el otro la mantiene abierta para transmitir paquetes de vuelta.

La apuesta limitada de Harding en infraestructura se amplía

Harding presentó Proxylity públicamente en mayo de 2025 con la tesis de que experimentar en software de red sigue siendo caro porque los desarrolladores deben construir infraestructura antes de probar una idea. En su publicación fundacional, enmarcó a UDP como una cuña inicial hacia hacer que los protocolos de red basados en mensajes sean más fáciles de desarrollar y desplegar.

La inscripción abierta de WireGuard empuja esa cuña más allá de los servicios privados con listas de peers cuidadosamente administradas. Le da a Proxylity una vía hacia la incorporación de dispositivos, clientes móviles y servicios cifrados públicos donde el servidor no puede conocer a cada participante de antemano. La entrega Async Lambda extiende el mismo gateway desde redes petición-respuesta hacia la automatización orientada a eventos.

Proxylity distribuye UDP Gateway a través de AWS Marketplace, manteniendo los cargos de compra y uso en la factura de AWS del cliente. Su precio actual incluye 1 millón de paquetes por mes sin cargo, seguido de $1.25 por millón para los siguientes 99 millones de paquetes. Cada Listener cuesta $0.00139 por puerto-hora, o aproximadamente $1 por mes, antes de los cargos por Lambda y otros servicios de AWS.

Esa estructura de precios respalda el argumento central de Harding: hacer que un experimento UDP sea lo suficientemente barato para comenzar sin comprometerse con infraestructura de red siempre activa. El lanzamiento de junio fortalece la proposición al eliminar dos formas de espera: el paso de registro antes de que un dispositivo desconocido se conecte y la ventana de ejecución sincrónica después de que llegue su paquete.

El compromiso es explícito. Los endpoints abiertos trasladan las verificaciones de identidad al código de la aplicación, y la entrega asíncrona elimina las respuestas inmediatas. Para flujos de trabajo de aprovisionamiento, telemetría y auditoría que ya operan bajo esas suposiciones, Proxylity ha convertido un paquete UDP cifrado en un punto de entrada directo para aplicaciones serverless de AWS.