Discussion :

[shepounet]

Bonjour à tous et à toutes,

Je suis en train de développer une application client/serveur. Sur un réseau privé, il n'y a aucun problème.
Le problème vient principalement des NATs et firewall souvent présent sur les réseaux de particuliers.

Soit deux machines A et B sur deux réseaux distincts. Les deux machines se trouvent derrière un NAT.
Les paquets envoyés de la machine A vers B (et inversement) se trouvent filtrés par le NAT. J'aimerais connaitre les différentes solutions pour éviter ce problème.

J'ai déjà étudié des solutions, plus ou moins bancales, contraignante pour l'utilisateur.
La première consiste à réaliser l'UDP hole punching qui consiste à s'enregistrer sur un serveur web afin de connaitre l'adresse distante de l'autre machine et d'ouvrir une communication en "forcant" le NAT/Firewall à ouvrir le port désiré et accepter les paquets de la machine distante.
Cette solution est bancale.

La deuxième solution consiste à faire interagir l'utilisateur en créant un tunnel VPN avec la machine distante. Cette solution implique d'accepter les paquets provenant du port 1723.
Une solution clairement contraignante pour l'utilisateur, et très peu souple.

J'aurais aimé savoir quels sont les autres moyens envisageables. Comment des logiciels (tel que Skype) arrivent à bypasser nos NATS/Firewalls à tous les coups.

Toute aide sera la bienvenue.
Cordialement,
shepounet

[thelvin]

La première consiste à réaliser l'UDP hole punching qui consiste à s'enregistrer sur un serveur web afin de connaitre l'adresse distante de l'autre machine et d'ouvrir une communication en "forcant" le NAT/Firewall à ouvrir le port désiré et accepter les paquets de la machine distante.
Cette solution est bancale.

Oui, tout comme la technologie du NAT. Il n'y a pas de solution élégante. Celle-ci est la plus efficace, et n'est pas contraignante pour l'utilisateur, mais pour toi : tu te retrouves obligé de fournir un serveur web.

Comment des logiciels (tel que Skype) arrivent à bypasser nos NATS/Firewalls à tous les coups.

Skype est presque le créateur de l'UDP hole punching. Ils font comme ça.

La plupart des services, ou bien quand le hole punching ne marche pas, font parler A et B en passant par le serveur. Le serveur relaie tous les échanges, au lieu de juste permettre de percer le premier trou.
C'est assez simple et souple, mais ça nécessite d'avoir des serveurs capables de relayer tout ça.