¿Qué significa realmente un tiempo de espera de conexión UDP?

18

Dado que UDP es un protocolo sin conexión, estoy confundido por la configuración de mi firewall de Sonicwall para "Tiempo de espera de conexión UDP". Se establece en un valor predeterminado de 30 segundos, pero ¿qué es exactamente el tiempo de espera después de 30 segundos?

Aquí está mi situación real en el mundo real: tengo un servidor NTP en el grupo ntp.org que atiende alrededor de 3000 consultas por minuto. Esto pone un poco de tensión en mi grado SOZ TZ-200, no en términos de ancho de banda; pero en términos de # de conexiones tiene que pasar a través de él. Me pregunto si las conexiones UDP de alguna manera se 'mantienen vivas' en SonicWall; a pesar de que son (por definición) sin conexión.

¿Que me estoy perdiendo aqui? ¿Qué quiere decir SonicWall cuando habla de un "Tiempo de espera de conexión UDP"?

sonicwall udp

— Jon Wadsworth
fuente

Los cortafuegos generalmente permiten paquetes para una conexión establecida por una máquina dentro del cortafuegos. Pero UDP no tiene conexiones. Entonces, las opciones son permitir todos los paquetes UDP, bloquear todos los paquetes UDP, o tratar de adivinar cuáles son las "conexiones UDP", de modo que solo permita los paquetes que son parte de esas "conexiones". Todos los proveedores de cortafuegos (?) Toman el último enfoque.

— user253751

Como ha descrito immibis. Debido a la traducción de direcciones de red o NAT, un enrutador de puerta de enlace de Internet / subred solo permitirá TCP (prácticamente todo el tráfico es TCP) en el que un cliente en la subred inicia la conexión. Porque no hay forma de asignar un puerto para NAT si la conexión es entrante. ¿Cómo sabe el enrutador a quién enviarlo? UDP ni siquiera tiene una conexión, entonces, ¿cómo va a manejar el enrutador las solicitudes UDP que llegan? Una forma es realizar un seguimiento de los paquetes UDP salientes.

— Mariscal artesanal

Si aloja un servidor, debe reenviar los puertos en los que espera recibir conexiones, aunque esté preparado para cualquier cosa.

— Mariscal artesanal

16

Si bien no existe una "conexión" formal con UDP, todavía existe una convención según la cual los clientes envían solicitudes y esperan recibir respuestas con la IP de origen y el puerto intercambiado con la IP y el puerto de Destinatoin.

Por lo tanto, los firewalls con estado y NAT suponen que los paquetes con una combinación dada de IP de origen / puerto de origen / IP de destino / puerto de destino y la combinación correspondiente con el origen y el destino intercambiados forman parte de una "conexión". Esto permite que se apliquen reglas como "solo conexiones salientes" a UDP y permite que se apliquen traducciones inversas a los paquetes de respuesta.

Lamentablemente, el firewall o NAT no tiene forma de saber cuándo el cliente ha terminado de hablar con el servidor. Por lo tanto, tiene que esperar un tiempo de espera antes de eliminar la entrada de sus tablas de seguimiento de estado. Ese es el tiempo de espera que está configurando.

En principio, sería posible construir una caja NAT que usara un enfoque sin estado para el reenvío de puertos mientras se mantiene un enfoque con estado para las conexiones salientes, pero es más simple usar NAT con estado para todo y parece que esto es lo que está haciendo su proveedor.

Desafortunadamente, como ha descubierto, esto es una mierda para los servidores UDP sin estado que atienden grandes cantidades de pequeñas solicitudes. Termina en una situación en la que el firewall consume muchos más recursos que el servidor en sí.

— Peter Green
fuente

2

Gracias por la gran respuesta Peter! En mi caso, SonicWall me permite reducir el "tiempo de espera de conexión" UDP en una regla de firewall en particular, por lo que reduciré la regla de la política NTP a 5 segundos (del valor predeterminado de 30).

— Jon Wadsworth

1

Nota: Después de hacer eso, vi que las 'conexiones totales' según lo informado por Sonicwall cayeron de ~ 1500 a ~ 400. ¡Perfecto! Gracias de nuevo por la gran respuesta.

— Jon Wadsworth

1

Tenga en cuenta que la mayoría de los protocolos de transmisión usan UDP, que incluye la porción de medios de VOIP (después de que se negocie usando SIP). Tener un tiempo de espera corto puede causar un problema si no hay tráfico (por ejemplo, llamada retenida, ambos lados silenciados, etc.) ya que no todos los teléfonos VOIP (duros o blandos) son excelentes para renegociar la conexión de medios si los puertos se caen . Otros usan un 'mantener vivo' enviando pequeñas señales de forma periódica, que bien podrían estar más separadas de 5 segundos.

— Chuck van der Linden

11

Su firewall está manteniendo una tabla de conexión para conexiones UDP. Por ejemplo, cuando envía una consulta DNS, el cortafuegos crea una entrada para ese flujo para que la respuesta DNS se permita nuevamente en su red. Las entradas en la tabla expiran después de 30 segundos sin actividad.

— Ron Trunk
fuente

Gracias Ron ¿Puedes comentar sobre esa tabla de conexión, con respecto a las conexiones entrantes? Dado que mi servidor NTP está en el interior, realmente no debería ser necesario 'mantener la puerta abierta' para esas conexiones entrantes, ya que mi servidor en el interior siempre puede volver a la fuente (tengo una salida abierta reglas). ¡Gracias por la rápida respuesta!

— Jon Wadsworth

3

La tabla de conexión se crea independientemente de la dirección de la conexión y en realidad se usa inmediatamente para el paquete de respuesta que regresa de su servidor a través del firewall que regresa al interrogador. El cortafuegos mantiene una tupla de (src ip, src port, dst ip, dst port) para asociar la consulta inicial con la respuesta. Como no hay realmente un semáforo para indicarle al cortafuegos que una sesión UDP particular ha finalizado y que el socket se ha cerrado, el valor de tiempo de espera termina siendo utilizado.

— rnxrx

2

Su servidor NTP está detrás de su NAT (firewall). UDP no tiene conexión desde el punto de vista de la aplicación y el SO y para la mayoría de los dispositivos de red en el camino.

Sin embargo, para su cortafuegos NAT, registra cada vez que se sale un paquete UDP para que una respuesta del otro extremo termine siendo redirigida a la misma computadora dentro de su red. Estos se llaman "conexiones" por el firewall.

Ahora, en teoría, el NAT sabe que el puerto externo será el puerto NTP conocido, pero parece que su firewall no es compatible con eso. Si este es su único uso para UDP a través de este firewall, puede establecer el tiempo de espera de conexión en un número menor. Alternativamente, si le permite configurar por puerto de aplicación, puede configurarlo en un tiempo menor (1 segundo, por ejemplo) para ese puerto específico.

— Alan
fuente

1

El tiempo de espera no es específico de NAT; cualquier firewall con estado tendrá uno.

— user1686

El cortafuegos no hace NAT en su lugar, está tratando de filtrar los paquetes que están en transición a través de NAT, por lo tanto, la interrelación con el enrutador y NAT.

— Mariscal artesanal

Un enrutador de puerta de enlace a Internet Debe emplear NAT porque cualquier computadora se encuentra en una subred, solo el enrutador de puerta de enlace tiene una dirección IP de Internet real. Sería un desperdicio inmenso si cada computadora fuera una cosa en Internet. El enrutador de puerta de enlace a veces tiene un gran grupo de computadoras que están asociadas con una dirección IP de Internet. Utiliza un zócalo web berkly para poder traducir uno a uno entre los paquetes entrantes de la web y las computadoras en su red. La gente parece no entender esto.

— Mariscal artesanal

0

IPv6 no necesita NAT, sin embargo, todavía parece que los firewalls tienen estado con respecto a UDP.

— David Howard
fuente