Qu'est-ce qu'un délai d'expiration de connexion UDP signifie vraiment?

18

Étant donné que UDP est un protocole sans connexion, je suis confus par le paramètre de mon pare-feu Sonicwall pour «Délai de connexion UDP». Il est réglé sur une valeur par défaut de 30 secondes - mais qu'est-ce qui expire exactement après 30 secondes?

Voici ma situation réelle: j'ai un serveur NTP dans le pool ntp.org qui sert environ 3000 requêtes par minute. Cela met un peu de pression sur mon grade SOHO TZ-200 - pas en termes de bande passante; mais en termes de nombre de connexions qu'il a traversé. Je me demande si les connexions UDP sont en quelque sorte «maintenues en vie» sur le SonicWall; même s'ils sont (par définition) sans connexion.

Qu'est-ce que j'oublie ici? Que signifie SonicWall lorsqu'il parle d'un "délai d'expiration de connexion UDP"?

sonicwall udp

— Jon Wadsworth
source

Les pare-feu autorisent généralement les paquets pour une connexion établie par une machine à l'intérieur du pare-feu. Mais UDP n'a aucun lien. Ainsi, les choix sont d'autoriser tous les paquets UDP, de bloquer tous les paquets UDP ou d'essayer de deviner quelles sont les "connexions UDP", donc n'autorisez que les paquets qui font partie de ces "connexions". Tous les (?) Fournisseurs de pare-feu adoptent la dernière approche.

— user253751

Comme l'a décrit immibis. En raison de la traduction d'adresses réseau ou NAT, un routeur de passerelle Internet / sous-réseau autorise uniquement TCP (pratiquement tout le trafic est TCP) dans lequel un client sur le sous-réseau initie la connexion. Car il n'y a aucun moyen d'attribuer un port pour le NAT si la connexion est entrante. Comment le routeur sait-il à qui l'envoyer? UDP n'a même pas de connexion, alors comment le routeur doit-il gérer les requêtes UDP entrant? Une façon consiste à garder une trace des paquets UDP sortants.

— vaisseau de maréchal

Si vous hébergez un serveur, vous devez transférer les ports sur lesquels vous prévoyez de recevoir des connexions, mais soyez prêt à tout.

— vaisseau de maréchal

16

Bien qu'il n'y ait pas de "connexion" formelle avec UDP, il existe toujours une convention selon laquelle les clients envoient des demandes et s'attendent à obtenir des réponses avec l'IP source et le port échangés avec l'IP et le port Destinatoin.

Les pare-feu avec état et les NAT supposent donc que les paquets avec une combinaison donnée d'IP source / port source / IP de destination / port de destination et la combinaison correspondante avec source et destination échangés font partie d'une "connexion". Cela permet d'appliquer des règles telles que «connexions sortantes uniquement» à UDP et d'appliquer des traductions inversées aux paquets de réponse.

Malheureusement, le pare-feu ou le NAT n'a aucun moyen de savoir quand le client a fini de parler au serveur. Il doit donc attendre un délai avant de supprimer l'entrée de ses tables de suivi d'état. C'est le délai d'attente que vous définissez.

En principe, il serait possible de construire une boîte NAT qui utilise une approche sans état pour les transferts de port tout en conservant une approche avec état pour les connexions sortantes, mais il est plus simple d'utiliser simplement le NAT avec état pour tout et il semble que c'est ce que fait votre fournisseur.

Malheureusement, comme vous l'avez découvert, cela craint pour les serveurs UDP sans état servant un grand nombre de petites demandes. Vous vous retrouvez dans une situation où le pare-feu consomme beaucoup plus de ressources que le serveur lui-même.

— Peter Green
source

2

Merci pour la grande réponse Peter! Dans mon cas, SonicWall me permet de réduire le «délai de connexion» UDP sur une règle de pare-feu particulière, je vais donc réduire la règle de la stratégie NTP à 5 secondes (contre 30 par défaut).

— Jon Wadsworth

1

Remarque: Après avoir fait cela, j'ai vu le `` total des connexions '' signalé par le Sonicwall passer de ~ 1500 à ~ 400. Parfait! Merci encore pour l'excellente réponse.

— Jon Wadsworth

1

Sachez que la plupart des protocoles de streaming utilisent UDP, ce qui inclut la partie média de VOIP (après avoir été négociée via SIP). Avoir ce court délai peut provoquer un problème s'il n'y a pas de trafic (par exemple, appel mis en attente, les deux côtés coupés, etc.) car tous les téléphones VOIP (durs ou doux) ne sont pas parfaits pour renégocier la connexion multimédia si les ports sont abandonnés . D'autres utilisent un «garder en vie» en envoyant de minuscules signaux sur une base périodique, qui pourraient bien être plus éloignés que 5 secondes.

— Chuck van der Linden

11

Votre pare-feu gère une table de connexion pour les connexions UDP. Par exemple, lorsque vous envoyez une requête DNS, le pare-feu crée une entrée pour ce flux afin que la réponse DNS soit autorisée à revenir sur votre réseau. Les entrées de la table expirent après 30 secondes d'inactivité.

— Ron Trunk
source

Merci Ron. Pouvez-vous commenter cette table de connexion en ce qui concerne les connexions entrantes? Étant donné que mon serveur NTP est à l'intérieur, il ne devrait pas vraiment être nécessaire de «garder la porte ouverte» pour ces connexions entrantes, car mon serveur à l'intérieur peut toujours revenir à la source (j'ai une sortie sortante grande ouverte règles). Merci pour la réponse rapide!

— Jon Wadsworth

3

La table de connexion est construite quelle que soit la direction de la connexion et est en fait immédiatement utilisée pour le paquet de réponse revenant de votre serveur via le pare-feu retournant au demandeur. Le pare-feu gère un tuple de (src ip, src port, dst ip, dst port) pour associer la requête initiale à la réponse. Puisqu'il n'y a pas vraiment de sémaphore pour indiquer au pare-feu qu'une session UDP particulière est terminée et que le socket a fermé, la valeur de timeout finit par être utilisée.

— rnxrx

2

Votre serveur NTP est derrière votre NAT (pare-feu). UDP est sans connexion du point de vue de l'application et du système d'exploitation et pour la plupart des appliances réseau.

Pour votre pare-feu NAT, cependant, il enregistre chaque fois qu'un paquet UDP sort afin qu'une réponse de l'autre extrémité finisse par être redirigée vers le même ordinateur à l'intérieur de votre réseau. Celles-ci sont appelées «connexions» par le pare-feu.

Maintenant, en théorie, le NAT sait que le port externe sera le port NTP bien connu, mais il semble que votre pare-feu ne le supporte pas. Si c'est votre seule utilisation pour UDP via ce pare-feu, vous pouvez définir un délai d'expiration de connexion plus petit. Alternativement, s'il vous permet de définir par le port d'application, vous pouvez le définir sur une durée plus courte (1 seconde, par exemple) pour ce port spécifique.

— Alan
source

1

Le délai d'attente n'est pas spécifique au NAT; tout pare-feu dynamique en aura un.

— user1686

Le pare-feu ne fait pas NAT au lieu de cela, il essaie de filtrer les paquets qui transitent par NAT, d'où l'interrelation avec le routeur et NAT.

— maréchal

Un routeur passerelle vers Internet Doit utiliser NAT car tout ordinateur se trouve sur un sous-réseau, seul le routeur passerelle a une adresse IP Internet réelle. Ce serait un énorme gaspillage si chaque ordinateur était une chose sur Internet. Le routeur passerelle a parfois un grand groupe d'ordinateurs qui sont tous associés à une adresse IP Internet. Il utilise un socket web berkly pour être capable de traduire un à un entre les paquets entrants du web et les ordinateurs de son réseau. Les gens semblent ne pas comprendre cela.

— vaisseau de maréchal

0

IPv6 n'a pas besoin de NAT, mais il semble toujours que les pare-feu soient dynamiques par rapport à UDP.

— David Howard
source