UDP y QUIC a través de proxies

Un proxy puede superar una comprobación web y seguir sin poder transportar el tráfico que necesita tu programa. Por ejemplo, un juego puede iniciar sesión mediante el proxy, pero no intercambiar las actualizaciones de la partida. Un sitio web puede abrirse normalmente mientras el navegador utiliza HTTP/2 en lugar de HTTP/3. Estas operaciones utilizan funciones de red distintas.

Para la elección general de protocolo, consulta Proxies SOCKS y HTTP. Este artículo explica cómo llega UDP a un destino a través de un proxy, qué necesita QUIC de esa ruta y cómo comprobar que tu aplicación utiliza el transporte y la IP de salida previstos.

Qué hacen UDP, QUIC y HTTP/3

TCP entrega un flujo ordenado de bytes. Si se pierden datos, organiza su retransmisión y retiene los bytes posteriores frente a la aplicación hasta completar el hueco. UDP envía mensajes separados, llamados datagramas. UDP por sí solo no garantiza entrega, orden ni protección frente a duplicados; el programa que lo utiliza decide cómo gestionar esas situaciones.

Esto permite a las aplicaciones elegir distintos comportamientos. Una aplicación de voz puede descartar un paquete de audio que llega demasiado tarde para reproducirlo. Un juego puede preferir una actualización de posición reciente a una antigua. Un intercambio DNS puede consistir en una pregunta y una respuesta breves. El transporte real depende del programa: estos ejemplos no significan que todas las llamadas, juegos o solicitudes DNS utilicen UDP.

QUIC es un protocolo de transporte construido sobre UDP. Añade establecimiento de conexión, recuperación de datos perdidos, control de congestión y flujos fiables. Un archivo transferido por un flujo QUIC fiable puede llegar completo y en orden. Que sus paquetes viajen dentro de datagramas UDP no elimina la fiabilidad que proporciona QUIC.

QUIC también permite que varios flujos compartan una conexión. Cuando se pierden datos de un flujo, otros cuyos datos han llegado pueden continuar. Esto puede reducir la espera frente a transportar todos los flujos por una sola conexión TCP ordenada. El resultado sigue dependiendo de la ruta, la pérdida de paquetes, el servidor y el cliente; elegir QUIC por sí solo no garantiza una aplicación más rápida.

HTTP/3 transporta HTTP sobre QUIC. HTTP/1.1 y HTTP/2 normalmente utilizan TCP. Los tres pueden servir un sitio HTTPS, por lo que https:// en la dirección no identifica la versión HTTP ni confirma que se haya utilizado UDP.

El cifrado es una propiedad separada. UDP no cifra los datos. QUIC utiliza TLS 1.3 para establecer la protección del tráfico de aplicación. Una aplicación UDP ordinaria puede utilizar otro mecanismo de seguridad o transmitir su carga útil sin cifrar; reenviarla a través de un proxy no añade automáticamente esa protección.

Cómo transporta SOCKS5 UDP

SOCKS5 define una retransmisión UDP: un servicio que acepta datagramas del cliente, envía su carga útil al destino y devuelve las respuestas. El cliente organiza primero este reenvío por TCP. Después, la conexión de control y la ruta de datagramas existen en paralelo.

1. El cliente se conecta al servidor SOCKS5 por TCP y completa el procedimiento de autenticación acordado.
2. Solicita UDP ASSOCIATE. Si el proxy acepta, la respuesta proporciona la dirección y el puerto UDP de retransmisión.
3. El cliente envía datagramas al retransmisor con una cabecera SOCKS que identifica el destino. El retransmisor retira esa cabecera antes de reenviar la carga útil. En las respuestas, añade una cabecera SOCKS antes de devolver el datagrama al cliente.
4. El cliente mantiene abierta la conexión de control TCP mientras utiliza la retransmisión. Cerrarla termina el reenvío UDP organizado por esa conexión. Esta relación entre la conexión de control y el reenvío UDP se denomina asociación UDP.

El retransmisor puede utilizar una dirección o un puerto distintos del punto TCP introducido en la configuración del proxy. Enviar UDP sin encapsular a ese punto conocido no realiza el intercambio SOCKS5. Un cliente que solo implementa CONNECT puede utilizar SOCKS5 para TCP, pero carece del procedimiento necesario aquí. SOCKS4 no define esta función de retransmisión UDP.

Esto explica un éxito parcial habitual: un cortafuegos permite la conexión TCP y la autenticación, pero bloquea los datagramas al retransmisor negociado. La contraseña funciona; la aplicación sigue sin recibir respuestas UDP. Ambas partes de la ruta deben estar disponibles.

¿Puede un proxy HTTP reenviar UDP?

Una solicitud HTTP CONNECT ordinaria pide al proxy abrir una conexión TCP con el destino y transportar un flujo de bytes. No establece reenvío UDP. Utilizar TLS para la conexión con un proxy HTTPS protege esa conexión sin cambiar el tipo de túnel solicitado.

HTTP dispone de un mecanismo adicional de túnel UDP, conocido habitualmente como CONNECT-UDP y desarrollado como parte de MASQUE. Con un cliente y un servidor compatibles, el cliente solicita un túnel hacia un destino UDP. El proxy reenvía los datagramas a ese destino y devuelve las respuestas. Esto requiere compatibilidad expresa en ambos lados.

En la conexión entre cliente y proxy, los datagramas HTTP pueden transportarse en tramas QUIC DATAGRAM cuando se admiten HTTP/3 y las extensiones necesarias. También pueden transportarse en cápsulas: mensajes delimitados dentro de un flujo HTTP fiable, incluido HTTP/2 sobre TCP. En ese caso, el proxy sigue enviando UDP al destino aunque la primera parte de la ruta utilice TCP.

Esa elección afecta a los tiempos. Si la conexión TCP pierde datos, los bytes posteriores pueden esperar a su recuperación, retrasando los datagramas transportados dentro de ellos. El túnel puede funcionar y aun así resultar inadecuado para una carga concreta en tiempo real. Introducir simplemente una dirección de proxy http:// en un programa no activa ninguno de estos mecanismos UDP adicionales.

¿Qué conexión utiliza QUIC?

La expresión «proxy QUIC» necesita contexto. Puede describir el transporte utilizado para llegar al proxy o la conexión de la aplicación con el destino. Son partes separadas del intercambio.

En la retransmisión UDP ordinaria, el proxy no necesita terminar la conexión QUIC de la aplicación. Reenvía paquetes mientras la aplicación y el destino siguen siendo los extremos de ese intercambio cifrado. El proxy sigue sabiendo a dónde reenvía tráfico y puede observar su volumen y sus tiempos.

Por qué importa la compatibilidad de la aplicación

Un programa necesita implementar el método de reenvío que ofrece el servicio. Una casilla SOCKS5 no indica si admite UDP ASSOCIATE. Del mismo modo, un programa puede admitir HTTP/3 en conexiones directas y ofrecer únicamente conexiones TCP mediante proxy.

Chrome ofrece un ejemplo concreto: su compatibilidad SOCKS5 incorporada encamina solicitudes de URL basadas en TCP y no retransmite UDP mediante SOCKS5. Cargar una página con ese ajuste no prueba la retransmisión UDP del servicio. Esta limitación afecta a ese modo concreto del cliente; otros clientes o programas externos de enrutamiento pueden tener funciones distintas.

Comprueba también el alcance del ajuste. El inicio de sesión, las descargas de archivos, la voz y la partida pueden utilizar componentes de red diferentes dentro de una misma aplicación. Un proxy configurado para solicitudes web puede cubrir solo algunos. Un ajuste de proxy del sistema también depende de que cada programa lo respete.

Un programa que redirige el tráfico de otra aplicación puede enviar su UDP a través de un proxy, siempre que admita UDP y el método de reenvío del servicio. Redirigir solo TCP no basta. Si el programa utiliza una interfaz de red virtual, sus reglas de enrutamiento deciden qué tráfico entra en ella. Prueba la combinación completa: la aplicación, el programa de enrutamiento y el punto de conexión del proxy.

Uso de una alternativa, fallo y conexión directa

Cuando la ruta necesaria no está disponible, el resultado depende de las funciones y la política de la aplicación. Tres resultados pueden parecer similares si la única pregunta es si algo se abrió:

Cambiar a una versión HTTP basada en TCP se denomina recurrir a una alternativa, o fallback. Puede mantener la navegación normal cuando QUIC no está disponible. El cliente abre otra conexión; QUIC no se convierte en TCP. Por tanto, desactivar QUIC puede ayudar a una aplicación web a utilizar una ruta TCP disponible, pero no puede proporcionar UDP a una función que lo requiere.

Ir directamente al destino es una decisión de enrutamiento. El UDP no compatible no se envía siempre directamente: el programa puede detenerse, probar otro transporte o seguir una regla de exclusión configurada. Si todo el tráfico de la tarea debe pasar por el proxy, utiliza un modo que se detenga cuando falle esa ruta y comprueba su comportamiento con el proxy no disponible.

Por qué puede dejar de funcionar UDP después del establecimiento

Reglas de puertos y ruta de retorno

El puerto TCP 443 y el puerto UDP 443 pertenecen a transportes distintos. Permitir uno no abre el otro. Para SOCKS5, el cliente debe llegar al punto de retransmisión UDP devuelto; el retransmisor también debe poder llegar al puerto UDP del destino. HTTP/3 puede utilizar puertos distintos de 443, por lo que debes comprobar el punto que realmente utiliza la aplicación.

Las respuestas deben volver a través del retransmisor, el cortafuegos y cualquier NAT, que traduce direcciones y a menudo puertos entre redes. Enviar un datagrama no demuestra por sí solo que funcione esa ruta de retorno. Un cambio de red puede alterar la IP pública del cliente o la correspondencia de puertos. Los retransmisores SOCKS5 deben rechazar los datagramas de una IP de origen distinta de la registrada para esa asociación UDP, por lo que una dirección cambiada puede requerir una asociación nueva.

Pausas y estado vencido

Los retransmisores y los dispositivos NAT mantienen registros temporales para los intercambios UDP. Esos registros pueden vencer durante una pausa. Una llamada o sesión puede funcionar al principio y después perder su ruta UDP hasta que el cliente la establezca de nuevo. Mantener la misma IP de salida no evita esto: el estado necesario para reenviar UDP y la asignación de IP del servicio son cosas separadas.

Tamaño del datagrama y MTU

MTU es el mayor paquete IP que un enlace de red puede transportar sin fragmentación. El tamaño utilizable a lo largo de una ruta queda limitado por el menor de esos límites, conocido como MTU de la ruta. Las cabeceras IP, UDP y las adicionales del túnel ocupan espacio en el paquete. Un mensaje de prueba pequeño puede pasar mientras se descartan datagramas mayores, por lo que la aplicación debe tener en cuenta toda la ruta y sus cabeceras añadidas.

Una ruta QUIC debe transportar al menos 1 200 bytes de carga útil UDP, sin contar las cabeceras IP y UDP. El cliente rellena los datagramas UDP que contienen sus paquetes QUIC Initial hasta alcanzar al menos ese tamaño de carga útil. Las cabeceras del proxy en el tramo entre cliente y proxy necesitan espacio adicional. Esto no recomienda configurar una MTU de interfaz de 1 200: explica por qué pueden funcionar una solicitud y respuesta DNS pequeñas mientras no pasa el intercambio QUIC inicial, de mayor tamaño.

Retardo, pérdida y carga

En una llamada o un juego, el tiempo de entrega puede importar tanto como la propia entrega. Un retardo variable, la pérdida de paquetes y los límites de frecuencia de paquetes pueden perjudicar una retransmisión UDP que, por lo demás, funciona. El ancho de banda por sí solo no describe esas condiciones. Un proxy añade otro tramo a la ruta; puede cambiar el rendimiento en cualquier dirección, según las redes y la carga.

Cómo verificar UDP y HTTP/3 a través de un proxy

Prueba la aplicación que piensas utilizar o un cliente que implemente el mismo método de reenvío. Una prueba útil comprueba la respuesta, el transporte y la dirección de salida del mismo intercambio.

1. Elige un destino que responda al tráfico necesario. Utiliza el servidor real de la aplicación o un respondedor UDP controlado. Para HTTP/3, elige un destino que sepas que lo admite. El silencio de un puerto UDP arbitrario no indica qué parte falló.
2. Confirma que se ha aceptado la retransmisión o el túnel. Con SOCKS5, examina el resultado de UDP ASSOCIATE y la dirección y el puerto de retransmisión devueltos. Con un túnel HTTP UDP, confirma su aceptación. La autenticación por sí sola no cubre este paso.
3. Completa una solicitud y una respuesta. Un respondedor controlado puede devolver un identificador de solicitud y registrar la IP de origen que vio. Esto comprueba la salida utilizada para ese intercambio UDP. Una comprobación web de IP separada solo cubre su propia solicitud.
4. Para HTTP/3, confirma el protocolo del intercambio con el destino. Busca HTTP/3 o h3 en el registro de conexión del cliente o del servidor, junto con pruebas de la ruta mediante proxy. Si el cliente de prueba dispone de un modo exclusivo de HTTP/3, puede revelar un fallo que el uso automático de una alternativa ocultaría.
5. Repite en condiciones relevantes: tamaños de datagrama realistas, tráfico sostenido y una pausa seguida de actividad. Si la tarea prohíbe el tráfico directo, prueba también qué sucede cuando el proxy no está disponible. Guarda la versión del cliente y la configuración de conexión con el resultado.

Una captura de paquetes puede ayudar a identificar la ruta. El reenvío UDP estándar de SOCKS5 envía datagramas al retransmisor negociado. En cambio, un túnel HTTP UDP puede utilizar una conexión TCP exterior, por lo que la ausencia de UDP en ese primer tramo no basta como prueba de fallo.

El DNS remoto y ping comprueban cosas distintas. Un proxy puede resolver un nombre de host para una conexión TCP sin retransmitir el tráfico UDP de la aplicación. El ping ordinario utiliza ICMP. Ninguna de estas pruebas sustituye a una solicitud y una respuesta UDP observadas en la ruta de proxy prevista.

Cuándo merece la pena elegir compatibilidad con UDP

Empieza por el tráfico que requiere tu tarea. El trabajo con sitios web y API que funciona por HTTP/1.1 o HTTP/2 puede quedar completamente cubierto por un proxy solo TCP. Las pruebas HTTP/3, el contenido multimedia UDP y otras funciones dependientes de UDP requieren una retransmisión o un túnel adecuados, además de un cliente capaz de utilizarlos.

Pregunta al servicio qué método de reenvío UDP y qué configuración de cliente admite. Después comprueba los destinos y puertos permitidos, los límites de tamaño de datagrama, el comportamiento durante la inactividad y cualquier límite de tráfico o frecuencia de paquetes relevante para la carga. Si TCP y UDP deben utilizar la misma IP de salida o ubicación, verifica ese requisito en la aplicación real. Una cuenta compartida o una comprobación web satisfactoria no demuestran un comportamiento de salida idéntico.