User:Bellefab/sandbox

Le UDP hole punching est une technique communement utilisée dans les sytèmes avec translation d'adresses (NAT) afin de maintenir une connexion UDP (User Datagram Protocol) traversant le NAT.

Les techniques de NAT traversal sont typiquement requises pour des applications réseaux sur Internet impliquant des hôtes dans des réseaux privés, par exemple pour les applications en peer-to-peer, Direct Client-to-Client (DCC) et pour le déployement de la VoIP (Voice over Internet Protocol).[1]

Le UDP hole punching établie la connectivité entre deux hôtes communiquant à travers un ou plusieurs traducteurs d'adresses. Typiquement, un hôte tiers présent sur le réseau public est utilisé pour établir les numéros de ports réseau qui seront utilisés pour une communication directe entre les hôtes privés.

Une fois que la communication a été établie, l'état des serveurs NAT est maintenu par un trafic de communication normal, ou en absence d'un tel trafic, par des paquets keep-alive (consistant généralement en paquets UDP vides ou en paquets ayant un contenu minimal).

Fonctionnement
Le UDP hole punching est une méthode pour établir une communication UDP bidirectionnelle, à travers Internet, entre deux hôtes situés dans des réseaux privés. Cette technique n'est pas applicable dans tout les scénarios ou avec tout les types de NAT, les caractéristiques du NAT n'étant pas standardisées.

Les hôtes se trouvant sur réseau privé et accédant à Internet par un NAT utilisent généralement la méthode Session Traversal Utilities for NAT (STUN) ou Interactive Connectivity Establishment (ICE) pour déterminer l'adresse publique du serveur NAT de l'autre bout de la communication.

Dans ce processus un autre hôte sur le réseau public est utilisé pour échanger les informations nécessaire à la communication directe entre les deux pairs.

Sur un serveur NAT, l'état d'une communication UDP expire après une certaine période, quelques dizaines de secondes généralement,, le UDP hole punching réenvoie donc périodiquement des paquets keep-alive pour s'assurer de la mise à jour des compteurs de la machine d'état du NAT et ainsi l'empêcher de clôre la communication.

Le UDP hole punching ne marche pas avec machines faisant du symmetric NAT (aussi appelé NAT bi-directionnel) qui se retrouve fréquement dans les réseaux de grosses entreprises.

Dans une approche plus élaborée, les deux hôtes commencent à émettre, et utilisent plusieurs tentatives. Sur un Restricted Cone NAT, le premier paquet de l'hôte distant sera bloqué. Ensuite le NAT enregistre le fait qu'il y ait eu l'envoi d'un premier paquet vers l'hôte distant et permettra la réception de tout paquet ayant l'adresse IP et le port de l'hôte distant.

Cette technique est communement utilisée dans les logiciels peer-to-peer et la téléphonie sur IP Voice over Internet Protocol. Elle peut également être utilisée pour permettre l'établissement d'un virtual private network sur UDP.

Cette technique est parfois étendue aux connexions TCP (Transmission Control Protocol), avec cependant moins de succès car les flux TCP sont controlés par l'OS hôte, pas par l'application et les numéros de ports sont sélectionnés aléatoirement; ainsi un NAT qui vérifiera les numéros de séquence considèrera les paquets comme non associés à une connexion exitante et les éliminera.

Etapes de la mise en place du Hole Punching
Soient A et B, deux hôtes, chacun sur son propre réseau privé;

Soient NA et NB les deux routeurs NAT avec des adresses publiques réspectives EIPA et EIPB;

Soit S est un serveur public avec une adresse IP publique connue.


 * 1) A et B commencent chacun un échange UDP avec S; les serveurs NAT NA et NB créent leurs états de translation UDP et assignent un numéro de port externe temporaire, EPA et EPB.
 * 2) S examine les paquets UDP pour connaitre les ports source utilisés par NA and NB (les ports NAT externes EPA et EPB).
 * 3) S communique EIPA:EPA à B et EIPB:EPB à A.
 * 4) A envoie un paquet à EIPB:EPB.


 * 1) NA examine le paquet de A et créé le tuple suivant dans sa table de translation: (Source-IP-A, EPA, EIPB, EPB).
 * 2) B envoie un paquet à EIPA:EPA.
 * 3) NB examine le paquet de B et créé le tuple suivant dans sa table de translation: (Source-IP-B, EPB, EIPA, EPA).
 * 4) Selon l'état de la table de translation de NA lorsque le premier paquet de B arrive, ce paquet est éliminé (s'il n'y a pas d'entrée dans la table de translation) ou accepté (si une entrée existe). Une entrée dans la table de translation est un tuple de la forme (Source-IP-A, EPA, EIPB, EPB).


 * 1) Selon l'état de la table de translation de NB lorsque le premier paquet de A arrive, ce paquet est éliminé (s'il n'y a pas d'entrée dans la table de translation) ou accepté (si une entrée existe). Une entrée dans la table de translation est un tuple de la forme (Source-IP-B, EPB, EIPA, EPA).
 * 2) Ainsi, des trous on été  créés dans les NAT, les deux hôtes peuvent communiquer directement. Dans le pire des cas, le second paquet de A atteint B et le second paquet de B atteint A.


 * Si les deux hôtes ont un Restricted cone NAT ou un Symmetric NAT, les ports externes du NAT vont différer de ceux utilisés pour S. Sur certains routeurs, les ports externes sont choisis séquentiellement, rendant ainsi possible l'établissement d'une conversation en devinant les ports choisis.

Voir également

 * ICMP hole punching
 * TCP hole punching
 * Hole punching (networking)
 * WebRTC
 * Port Control Protocol (PCP)

Liens externes

 * Peer-to-Peer Communication Across Network Address Translators, PDF – contient une explication détaillé du procesus de Hole Punching
 * Netfilter Connection Tracking and NAT Implementation – contient des informations sur l'implementation du NAT et du suivi de connexion du noyau Linux
 * STUNT – Simple Traversal of UDP Through NATs and TCP too
 * Network Address Translation and Peer-to-Peer Applications (NATP2P)

Category:Computer network security