Discussion :

[Beginner.]

Salut,

Comment rendre une machine accessible depuis internet ? La machine cela peut-être un PC, un smartphone, une carte arduino, une caméra...

J'ai lu beaucoup de chose à ce propos mais c'est compliqué et trop théorique, au final je ne sais pas si c'est faisable avec toutes les technologies qui sont mentionnées ici et là, je me demande si il n'y a pas des secrets bien gardés dans ce domaine... Pourtant il existe plusieurs applications VoIP connues qui fonctionnent... En effet on voit bien qu'on peut contacter quelqu'un (audio / vidéo) à tout moment...

- Bon je sais qu'il y a la redirection de port "manuelle" que l'on peut faire sur les boxes mais il faut une boxe et en plus ce n'est pas bon coté sécurité si j'ai bien compris...

Et apparemment on peut accéder à distance à certaines caméras du commerce sans avoir à faire de redirection de port du coup je me demande quelle technique est utilisée ? J'ai vu qu'il y avait des technologies comme P2P, UPnP, WebRTC... Mais c'est un sujet plutôt difficile apparemment...

- UPnP permettrait de faire des redirections de ports d'une manière "automatique" mais du coup cela pose aussi des soucis coté sécurité... Et là aussi je ne sais pas si c'est faisable sur les routuers autres que les boxes...

- P2P : J'ai lu qu'une machine A pourrait se connecter à une machine B si elle (la machine A) connait l'adresse IP publique et le port* de la machine B. (* Pour connaitre l'adresse IP publique et le port on utiliserait un serveur STUN).

Mais là je ne comprends pas :

1- je croyais que les connexions entrantes étaient bloquées ?
2- Le serveur STUN qui donne l'adresse IP publique et le port me fait penser à certains sites qui nous donnent aussi ces infos mais quand je teste je m’aperçois que le port change donc je ne vois pas comment cela peut servir à se connecter...

Je suis un peu perdu...

-------------
PS : Concernant le P2P et webRTC :

Exemple d'application : Building an Internet-Connected Phone with PeerJS.

Pour fonctionner il faut un serveur STUN et aussi parfois un serveur TURN mais à cette page ici il est dit :

The peer server will handle the signalling required for WebRTC for us, so we don't have to worry about STUN/TURN servers or other protocols

C'est la lib PeerJS qu s'en occupe pour nous du moins pour le serveur stun car il utilise ceux de google apparemment qui serait gratuit ???

[becket]

Salut,

Alors oui, évidement, c'est possible.

Ton serveur STUN n'est qu'un proxy qui fait office de tier public. Sans rentrer dans les détails, ton device (A) qui est dans ton LAN ( et même derriere un NAT ) ouvre une connexion ( par exemple d'un tunnel ) vers le serveur tiers (T) et lorsque un client I se connecte sur le serveur (T) pour le client (A), le serveur T fait suivre la connexion dans un tunnel.

[Beginner.]

Salut et merci,

Ton serveur STUN n'est qu'un proxy qui fait office de tier public. Sans rentrer dans les détails, ton device (A) qui est dans ton LAN ( et même derriere un NAT ) ouvre une connexion ( par exemple d'un tunnel ) vers le serveur tiers (T) et lorsque un client I se connecte sur le serveur (T) pour le client (A), le serveur T fait suivre la connexion dans un tunnel.

Alors justement ce que je comprends/déduis :

- Pour que le client I puisse (à l'aide du serveur STUN) contacter le client A il faut obligatoirement que ce dernier se soit préalablement connecté au serveur STUN.

Ce qui est logique en effet pour que le serveur STUN puisse donner au client I les informations nécessaires pour qu'il puisse contacter le client A il faut que ce dernier se soit préalablement connecté au serveur STUN (lors de cette connexion le serveur récupère l'adresse IP publique et le port du client A).

- Cela suppose que ces informations soient régulièrement mises à jour voire même qu'elles soient mises à jour à chaque fois que ces informations changent, ce qui implique donc que le client A doivent se connecter au serveur STUN à chaque changement, c'est bien ça ?

- Mais ma question du premier message est toujours d'actualité :

Est-ce que le client I peut se connecter au client A juste en ayant ces informations à savoir l'adresse IP publique et le port du client A ? C'est pourtant une connexion entrante qui devrait à priori être bloquée* par le routeur / NAT du client A, non ? (* à moins qu'une redirection de port ait été effectuée ?).

Ou bien peut-être qu'ici on est dans un cas particulier : lors de la connexion du client A au serveur STUN, le routeur du client A ouvre un port et c'est justement ce port ouvert (+ l'adresse IP publique du routeur) qui est conservé pour être fourni au client I ???

Est-ce possible ?

Je suis conscient que c'est un sujet compliqué pour lequel il est difficile de trouver des d'infos claires et pratiques...

[becket]

Est-ce que le client I peut se connecter au client A juste en ayant ces informations à savoir l'adresse IP publique et le port du client A ? C'est pourtant une connexion entrante qui devrait à priori être bloquée* par le routeur / NAT du client A, non ? (* à moins qu'une redirection de port ait été effectuée ?).

Non, il n'en à pas la possibilité. Hormis redirection de port

Ou bien peut-être qu'ici on est dans un cas particulier : lors de la connexion du client A au serveur STUN, le routeur du client A ouvre un port et c'est justement ce port ouvert (+ l'adresse IP publique du routeur) qui est conservé pour être fourni au client I ???

L'explication la plus simple est l'explication du tunnel.

A ouvre une connexion vers T, la communication continue tant que le client A est présent, à intervalle régulier le client A envoyer des "je suis toujours la".
Lorsque le client I connecte le serveur T pour A, il redirige le flux dans la communication existante entre T et A.

Du point de vue de ton routeur, ce n'est qu'une seule communication jamais interrompue entre A et T