Discussion :

[stalacta]

Bonjour à tous !

Je suis d'habitude cantonné au forum Python, mon premier langage de programmation et le seul dont je me sers vraiment mais dans le cadre de mes projets je suis amené à mettre une discussion du forum Python ici. La question touchant à pas mal de domaines en même temps, je l'ai mise directement sur le forum général. Je m'explique :

Je développe des programmes (en Python) qui touchent au réseau depuis quelque temps : envoi de fichiers, diffusion de flux audio/vidéo... et je me sers beaucoup du protocole TCP, c'est d'ailleurs lui que j'aimerai utiliser pour résoudre mon problème. J'y viens : pour l'instant, dès que je veux établir une connexion hors réseau local, je dois ouvrir un port sur ma livebox (dans mon cas, mais ça peut également être un autre routeur). Dans ce cas, le serveur et le client peuvent s'envoyer des données même s'il n'y a que le serveur qui a un port d'ouvert sur son routeur. Outre les failles de sécurité potentielles, pour moi la manipulation ne pose pas de problème, mais si je veux diffuser mon programme et qu'il soit utilisé par des gens qui ne s'y connaissent pas bien, j'aimerai trouver un autre moyen d'établir une connexion distante sans avoir besoin d'effectuer cette manipulation.
C'est alors qu'après de vaines recherches (à part avoir un vpn du genre hamachi qui ne me convient pas) que j'ai eu une idée mais je n'ai pas trouvé comment la mettre en place (quel que soit le langage, s'il y a une solution, je suis preneur) :
Dans notre cas, on considère que les IP sont connues de chaque ordinateur.
1) Les deux futurs correspondants initialisent un socket
2) Un ordinateur "client" envoi une requête TCP via son socket, tout ce qu'il y a de plus normal, à une seconde s
3) A une seconde s+1, l'autre ordinateur (qui n'a pas reçu la requête puisque son routeur n'est pas configuré pour la rediriger) simule la réception du paquet - qui est connu d'avance par les deux ordinateurs - puis envoi une réponse
4) Là, normalement, je ne sais pas comment mais ça à l'air de marcher lors d'une connexion normale, le client doit recevoir le paquet même sans avoir configuré le routeur. Il renvoi le dernier paquet nécessaire pour valider la connexion. A partir de là les deux devraient pouvoir recevoir les données, ou au moins le "client"

Pour la première étape, pas de problème. Pour la 2ème non plus. C'est à partir de la 3ème que je ne sais pas comment faire, j'ai bien tenté de trouver des exemples de paquets réponse, je ne sais pas trop comment m'y prendre pour tout ça. Peut-être avec un paquet à IP usurpée envoyée à l'ordinateur par lui-même afin de "tromper" le socket serveur.

Je me demande comment on peut mettre cela en place, si c'est possible. Si vous avez une autre idée, je serais enchanté de savoir comment je peux faire !

Merci d'avance de vos réponses !

[ram-0000]

Un autre possibilité, c'est le protocole UPnP. Avec ce protocole, lorsque le serveur se lance, il envoie une requête UPnp (en broadcast probablement ou alors à sa gateway par défaut) demandant d'ouvrir un port spécifique.

C'est supporté par beaucoup de box et aussi certains firewalls professionnels. C'est simple et souple (par contre, c'est un peu au détriment de la sécurité puisque cela ouvre un port sans que l'admin soit au courant ). L'utilisateur n'a rien à faire, cela sera pris en compte directement par ton équipement réseau (s'il support UPnP et si c'est activé)

[Invité]

Salut,

s'il était possible d'établir une connexion TCP entrante au travers d'un firewalll sans ouvrir le(s) port(s) cible(s), ça se saurait (hors VPN bien sûr, qui consiste à encapsuler)

Et je ne vois pas comment tu pourrais "proxyfier" un TCP SYN pour l'envoyer au stack du serveur. Comment voudrais-tu déclencher ce paquet ?

Steph

[sevyc64]

1) ok
2) ok, pourquoi pas
3) Comment est déterminer "s+1", comment le serveur sait que c'est "s+1", le moment d'envoyer sa réponse, puisqu'il n'a ps reçu la requete. Comment la synchronisation se fait (et se maintient au fil du temps)?
De plus, il va être difficile d'envoyer une réponse si la requete n'est pas passée auparavant dans l'autre sens. Ce n'est peut-être pas le cas des box, mais de nombreux routeurs, ou les firewalls doivent filtrer ce genre de message
4) Idem, il y a de forte chance que le routeur ou le firewall filtre en entrée ce genre de message, la réponse ne correspondant pas à une requete émise auparavant. Tu vas me dire que le client a bien émis la requete, mais la réponse ne peut, de toute façon pas correspondre puisque la requete puisque il est dit que le serveur n'a pas reçu la requete (dans le protocole TCP, les échanges se synchronisent sur des éléments qui font appel à un coté aléatoire lors de l'émission de la première requete par le client, et que donc le serveur, par définition, ne peut connaitre)

[stalacta]

Tout d'abord, merci de toutes vos réponses !

1) ok
2) ok, pourquoi pas
3) Comment est déterminer "s+1", comment le serveur sait que c'est "s+1", le moment d'envoyer sa réponse, puisqu'il n'a ps reçu la requete. Comment la synchronisation se fait (et se maintient au fil du temps)?
De plus, il va être difficile d'envoyer une réponse si la requete n'est pas passée auparavant dans l'autre sens. Ce n'est peut-être pas le cas des box, mais de nombreux routeurs, ou les firewalls doivent filtrer ce genre de message
4) Idem, il y a de forte chance que le routeur ou le firewall filtre en entrée ce genre de message, la réponse ne correspondant pas à une requete émise auparavant. Tu vas me dire que le client a bien émis la requete, mais la réponse ne peut, de toute façon pas correspondre puisque la requete puisque il est dit que le serveur n'a pas reçu la requete (dans le protocole TCP, les échanges se synchronisent sur des éléments qui font appel à un coté aléatoire lors de l'émission de la première requete par le client, et que donc le serveur, par définition, ne peut connaitre)

Pour ce qui est de la synchronisation, je pensais utiliser, à défaut d'avoir un serveur à Ip fixe personnel, une boîte de messagerie. Après, mes connaissances sur ce type de protocole ne sont que théoriques, je n'ai pas regardé de code source permettant de mettre en place le protocole. C'est justement pourquoi je vous demandais s'il était, selon vous, possible de mettre en place ce genre de choses. Pour ce qui est de l'aléatoire, je pense envoyer tout ça en plus sur le serveur de messagerie. Même si ce n'est pour l'instant pas optimisé comme programme, je pense, pour tester, créer une messagerie (orange par exemple) ou un compte dans un stockage de fichiers en ligne, puis chaque ordinateur met son IP, ensuite quand l'un veut se connecter, il upload un fichier / envoi un e-mail définissant une heure de connexion (on suppose que les horloges deux ordinateurs seront synchronisés à quelques secondes près) et on s'en sert pour relayer les informations. Si le tout marche, on se servira de la connexion pour des flux en temps réel et plus sécurisés.

Pour ce qui est du protocole UPnp, je me charge de regarder ses avantages, inconvénients et possibilités de compatibilité avec Python et je vois si ça vaut le coup d'adapter certains programmes avec ce protocole .

[Invité]

ensuite quand l'un veut se connecter, il upload un fichier / envoi un e-mail définissant une heure de connexion (on suppose que les horloges deux ordinateurs seront synchronisés à quelques secondes près) et on s'en sert pour relayer les informations. Si le tout marche, on se servira de la connexion pour des flux en temps réel et plus sécurisés.

Mais ça ne résoud pas le problème d'ouverture de port TCP cible s'il y a un firewall le long du transit physique des paquets...

D'autre part, TCP n'est pas adapté pour transporter des flux temps réel.

Steph