problème avec socket internet et routeur

Version imprimable

bonjour à tous,
Je suis en train de faire des essai avec les sockets et donc j'ai fait une petite application chat client/serveur qui marche sans problème sur mon réseau.
Là où sa foire c'est quand j'essai de la faire marcher par internet et en plus derrière des routeurs. Bon je sais pas si j'ai été très clair mais voici les schémas :D :

ça sa marche :
http://img186.imageshack.us/img186/2...uteurokji0.jpg
C'est sa qui foire :
http://img300.imageshack.us/img300/5...urpasokba7.jpg

voici les codes :

serveur :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
#include <stdio.h>
#include <winsock2.h>
#include "iostream"
#include "Sthread.h"
 
using namespace std;
 
//structure dans laquelle sera contenu les info, pour le thread de réception
typedef struct params params;
struct params
{
    SOCKET sock;
    char buffer[50];
};
 
//thread pour la récup des messages
void functionthread(void* param) // pas très propre mais c'est juste pour un essai
{
  params* p=(params*)param;
  char buffer[50];
 
  while(1)
	{
         memset(buffer,0,sizeof(buffer));
         recv(p->sock,buffer,sizeof(buffer),0);
         cout<<buffer<<endl;
	}
}
 
int main(int argc, char* argv[])
{
 
        cout << "NETWORK serveur"<<endl;
	system("TITLE NETWORK serveur");
 
	WSADATA wsa;
	WSAStartup(MAKEWORD(2,0),&wsa);
 
	SOCKET server;//Le socket qui servira à écouter sur un port
	SOCKET sock;//le socket qui servira à communiquer
 
	SOCKADDR_IN sinserv;	//parametres pour server
	SOCKADDR_IN sin;		//parametres pour sock
 
        params p; //structure dans laquel il y aura les paramètres pour le trhead  de récup
 
 
 
	int port;
 
	cout << "port :"<< endl;
	cin >> port;
 
	sinserv.sin_family=PF_INET;	
	sinserv.sin_addr.s_addr=INADDR_ANY;//Pas besoin d'ip pour le server
	sinserv.sin_port=htons(port);
 
	server=socket(PF_INET,SOCK_STREAM,0);
 
	//SOCK_STREAM pour le TCP
 
 
 
	bind(server,(SOCKADDR*)&sinserv,sizeof(sinserv));
 
	listen(server,0);//On se met à écouter avec server, 0 pour n'accepter qu'une seule connection
 
	char buffer[50];//Pour stocker les messages
	string buffer2;
	int sinsize;
	int err=0;//pour détecter si la connection est toujours valide
 
 
    //creer le trhead pour la récup des infos du client.
 
    Sthread Sth((void*)functionthread,&p);
 
 
	while(1)
	{
		sinsize=sizeof(sin);
		if((sock=accept(server,(SOCKADDR*)&sin,&sinsize))!=INVALID_SOCKET)
		{
 
		    cout << "connecter à "<< inet_ntoa(sin.sin_addr)  <<endl;
		    p.sock=sock;
		    Sth.start();
 
 
			while(err>-1)
			{
			 memset(buffer,0,sizeof(buffer));
			 getline(cin, buffer2);
		         sprintf(buffer,"%s",buffer2.c_str());
			 buffer[strlen(buffer)]='\0';
			 err=send(sock,buffer,strlen(buffer),0);
 
			}
                    Sth.stop();
		}
	}
 
}

et le client :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#include <stdlib.h> 
#include <iostream> 
#include <winsock2.h> 
#include "Sthread.h"
 
using namespace std; 
 
typedef struct params params;
struct params
{
    SOCKET sock;
    char buffer[50];
};
 
//thread pour la récup des messages
void functionthread(void* param) // pas très propre mais c'est juste pour un essai
{
  params* p=(params*)param;
  char buffer[50];
  int err=0;
 
  while(1)
	{
         memset(buffer,0,sizeof(buffer));
         recv(p->sock,buffer,sizeof(buffer),0);
         cout<<buffer<<endl;
	}
}
 
 
 
int main(int argc, char* argv[]) 
{  
 
        cout << "NETWORK client" << endl;
 
        WSADATA wsa; 
	WSAStartup(MAKEWORD(2,0),&wsa);	
	SOCKET sock;
	SOCKADDR_IN sin;
	char ip[15];
	int port;
	printf("Ip : ");
	cin >> ip;
	printf("%s","Port : ");
	cin >> port;
 
        params p; //structure dans laquelle il y aura les paramètres pour le trhead de récup
 
	sin.sin_family=PF_INET; 
	sin.sin_addr.s_addr=inet_addr(ip);
	sin.sin_port=htons(port);
	sock=socket(PF_INET,SOCK_STREAM,IPPROTO_TCP);
 
      if(connect(sock,(SOCKADDR*)&sin,sizeof(sin)))
	{
 
		cout << "la connection à echouee" << endl;
		system("PAUSE");
		exit(0);
	}
 
	char host[50];//pour stocker le nom de l'ordi local
	gethostname(host, sizeof(host));//obtient le nom de l'ordi local
 
        cout << host << " connecte a " << ip << endl;
 
	char buffer[50];
	string buffer2;
	memset(buffer,0,sizeof(buffer));
 
	int err=0;
	Sthread Sth((void*)functionthread,&p);
	p.sock=sock;
	Sth.start();
	while(err>-1)//qn y'a err=-1 c'est que la connection foire
	{
	 getline(cin, buffer2);
	 sprintf(buffer,"%s",buffer2.c_str());
	 err=send(sock,buffer,strlen(buffer),0);//on envoie 
	 memset(buffer,0,sizeof(buffer));)
	}
 
	cout << "connection terminee" << endl;
        Sth.stop(); 
	WSACleanup();
 
 
 system("pause"); 
 return 0; 
}

comment faire pour que sa marche ? j'ai chercher sur google mais j'ai rien trouvé. Y doit bien y avoir une solution puis que des logs comme logmein le font
merci d'avance. :D

29/06/2008, 18h57
wiztricks

questions!

Pour l'instant le code 'fonctionne', tu as plutôt un problème d'adressage.

Dans le deuxième shéma qui sont serveur et client?
est ce que ping, telnet fonctionnent?

Dans ton premier schéma, serveur et client sont dans le sous réseau 192.168.1.
Dans le deuxième shéma tu as deux sous réseaux "192.168.1." et un truc magique qui s'appelle en général NAT qui permet à des systèmes appartenant à ces deux sous réseaux de se 'parler'.
=> Pour les systèmes du réseau 192.168.1 de gauche, les adresses des systèmes du sous réseau "192.168.1." de droite ne peuvent être "192.168.1" mais nécessairement autre chose...

Si les serveurs de droite et de gauche ont des noms différents, peut être que nslookup du noms (ou ping du nom) te sortira l'adresse IP a entrer dans le client.
=> Modifier le client pour qu'il accepte des noms plutôt que des adresses? Ca éviterait de se planter entre les addresses 'locales" et distantes.

- W
29/06/2008, 19h21
tir0nik

merci pour ta réponse
on va dire que l'addresse 192.168.1.3 de gauche fait serveur et que l'addresse 192.168.1.2 de droite fait le client :D
on suppose que le client connait l'adresse publique du serveur (celle du routeur) mais ne sait pas quel ordi des 3 fait serveur. Comment trouver cette ordi (en supposant qu'il y en ai qu'un seul qui fasse serveur pour pas compliquer les choses :lol:). Et même une fois qu'on l'as trouvé (le nom ou l'ip locale) comment on fait pour qu'ils communiquent ?
Et je n'ai pas très bien compris comment fonctionne nslookup :lol:
29/06/2008, 19h31
Lucien63

Il faut configurer ton routeur coté serveur pour diriger les requetes client vers le serveur.
29/06/2008, 19h36
tir0nik

Citation:

Envoyé par Lucien63

Il faut configurer ton routeur coté serveur pour diriger les requetes client vers le serveur.

Oui j'avais deja vu sa en recherchant sur internet, mais j'aimerai trouvé un moyen pour que l'utilisateur n'ai pas à faire ça, comment font les logiciels comme logmein pour que sa marche sans avoir à configurer son routeur ?
29/06/2008, 19h42
wiztricks

C'est pas magique!
Si tu expédies la demande de connexion au routeur à l'adresse 72.245.x.y comment sait-il qu'il faut le transmettre à 192.168.1.x?

Le NATing offre une solution en permettant la définition d'adresses dans le sous réseau 72.245.x.y qui vont être associées à 192.168.1.x de façon temporaire ou permanente.

Tu peux aussi modifier le boîtier 'routeur' pour qu'il expédie les requêtes à la bonne machine interne en fonction du numéro de 'port'.

Les solutions dépendent en fait des possibilités des routeurs à faire autre chose que du routage classique...
En tout cas, ce n'est pas en regardant ton code que tu trouveras une solution.

- W
29/06/2008, 20h06
tir0nik

Supposons que le client connaisse l'adresse ip publique du serveur (dans l'ex : 88.221.36.121),son adresse locale (dans l'ex :192.168.1.3) ,son nom (par ex ordi-15asd4) et le port. Est-ce qu'à partir de là le client peut "demander" une connexion avec le serveur ? si possible sans avoir à ouvrir la page de configuration du routeur :P
29/06/2008, 20h17
wiztricks

Citation:

Envoyé par tir0nik

Supposons que le client connaisse l'adresse ip publique du serveur (dans l'ex : 88.221.36.121),son adresse locale (dans l'ex :192.168.1.3) ,son nom (par ex ordi-15asd4) et le port.

Est-ce qu'à partir de là le client peut "demander" une connexion avec le serveur ? si possible sans avoir à ouvrir la page de configuration du routeur :P

A priori, seule l'adresse IP publique et le numéro de port sont nécessaires.
Mais je suppose que tu as déjà fait l'essai? Donc çà ne suffit pas... et comme çà marche en local, il va peut être ouvrir la page de configuration du routeur ;-(

Est-ce que d'autres protocoles 'fonctionnent' style: PING, TELNET, FTP,...?
Si oui, est ce qu'on tape sur le 'bon serveur'?
- W
29/06/2008, 20h23
tir0nik

Oui les protocoles PING et FTP fonctionnent (aucune idées pour TELNET).
Sa veut dire quoi "on tape sur le 'bon serveur'" ?
Mais alors comment fonctionnent WLM, logmein, pc anywhere,...?
29/06/2008, 21h06
wiztricks

Citation:

Envoyé par tir0nik

Oui les protocoles PING et FTP fonctionnent (aucune idées pour TELNET).
Sa veut dire quoi "on tape sur le 'bon serveur'" ?
Mais alors comment fonctionnent WLM, logmein, pc anywhere,...?

Depuis le système client essaie de te connecter au serveur via telnet adresse-ip port (vérifie la syntaxe 'locale' pour faire çà).

Note: si tu es sûr que FTP et PING fonctionnent dans ces conditions, on va supposer que le réseau a été correctement construit pour que les systèmes se parlent. Il peut y avoir une une fonction de pare-feu qui t'empêche de passer (en fonction du numéro du port).
- W
30/06/2008, 00h32
tir0nik

telnet marche en local, j'ai pas encore pu essayer depuis l'exterieur. En fait est-ce que c'est possible que mon programme serveur puisse "regarder" tout ce qui passe par le port spécifié sur le routeur ?
et oui il y à un pare-feu dans mon routeur mais les échanges ne marchent quand meme pas sur les ports "autorisés" (80 par ex).
30/06/2008, 09h21
wiztricks

hmmm

Le piège avec les problèmes réseau est que le nombre d'objets devient rapidement source de confusion.

Reprend le 2ème shéma de ton 1er post, fait apparaitre.
1 - le client, le serveur?
2 - les flux TCP/IP (ping, ftp, telnet) qui fonctionnent (ou pas)

Je vais aller bosser.
Bon courage.
- W
30/06/2008, 10h04
tir0nik

voila comment sa marche :
http://img70.imageshack.us/img70/764...urpasokzd3.jpg
30/06/2008, 10h06
wiztricks

croix rouges

Elles veulent dire quoi?
-W
30/06/2008, 10h25
tir0nik

les croix rouges (ok je suis pas graphiste :lol:) montre ce qui ne marchent pas.
Je peux faire un ping sur la machine distante mais que sur l'ip publique et le telnet ne marche pas non plus (en plus je sais pas trop comment sa marche ce truc).
Pour le ftp j'ai pas essayé d'en créer un sur la machine serveur et de me connecter avec le client (possible ?).
30/06/2008, 10h57
wiztricks

Comment 'passer à travers' le routeur pour accéder aux systèmes du sous réseau "192.168.1" ?

C'est une question relative aux fonctions de 'pare-feu' du routeur qui peuvent être résolues de différentes façons en fonction de l'équipement.

Tant que tu n'as pas résolu cette question, pas la peine d'aller plus loin.

Essaie de formuler la question dans le forum 'réseau' en précisant le modèle de boîtier que tu utilises comme routeur.
Bon courage,
-W
30/06/2008, 11h12
nicroman

Je vais pas faire un cours de réseaux, mais bon... voici ce qu'il se passe:

Cas 1: Le client demande à se connecter au serveur en utilisant l'addresse privée 192.168.1.3 de gauche. Disons que le port du serveur soit 80.
- Demande de l'application client (192.168.1.2:30357 à droite) vers 192.168.1.3:80
- La pile TCP/IP du client va chercher à qui transmettre cette demande par la table de routage: 192.168.1.0 c'est le réseau local => on va donc envoyer la requete à 192.168.1.3 lui même
- La pile TCP/IP va chercher l'addresse (MAC) de la carte réseau qui correspond à 192.168.1.3 (protocole ARP) => @ du 192.168.1.3 de droite
- La demande va etre envoyée à 192.168.1.3 de droite, qui sera incapable de répondre.

Cas 2: Le client demande à se connecter au serveur en utilisant l'addresse publique 88.221.36.121 de gauche. Disons que le port du serveur soit 80.
- Demande de l'application client (192.168.1.2:30357 à droite) vers 88.221.36.121:80
- La pile TCP/IP du client va chercher à qui transmettre cette demande par la table de routage:88.221.36.121 c'est hors du réseau local => on va donc envoyer la requête au "gateway" par défaut (192.168.1.1 probablement).
- La pile TCP/IP va chercher l'addresse (MAC) de la carte réseau qui correspond à 192.168.1.1 (protocole ARP) => @ du routeur de droite
- La demande va etre envoyée au routeur de droite
- Le routeur récupère le paquet (de 192.168.1.2:30357 vers 88.221.36.121:80). S'apercoit que c'est un paquet "internet"/NAT. Il commence donc par allouer un port chez lui (20789 par exemple) et le fait correspondre à 192.168.1.2:30357... Puis il bidouille le paquet (IP masquerading), et balance sur Internet un paquet de 72.245.231.1:20789 vers 88.221.36.121:80
- Le route de gauche récupère le paquet en question....

Cas 2.a. On n'a rien spécifié sur le routeur de gauche:
- Le routeur ne sait pas quoi faire du paquet... et renvoyer un "connection failure"

Cas 2.b. On a dit au routeur que tout ce qu'il recoit sur le port 80 doit être envoyé à 192.168.1.3:80
- Le routeur va bidouiller le paquet (IP masquerading), et essaye de forwarder un paque de 72.245.231.1:20789 vers 192.168.1.3:80
- La pile TCP/IP du routeur "vois" que 192.168.1.3 est sur le brin 'local' et donc transmet le paquet à 192.168.1.3 himself
- Recherche de l'addresse MAC de 192.168.1.3 => @ du serveur
- Envoi du paquet à l'addresse MAC

Et voilà... le serveur à reçu un paquet qui ne correspond en rien à l'original (sauf pour les données):
Paquet emis: de 192.168.1.2:30357 pour 88.221.36.121:80
Paquet reçu: de 72.245.231.1:20789 pour 192.168.1.3:80

Bon... alors... comment entrer dans le Cas 2.b. sans configuration du routeur de gauche ?
- Utilisation de UPnP-IGD (non recommandé en raison des failles de sécurité que cela engendre)
- Utilisation d'un NAT "conique" du coté gauche... Mais cela demande d'apater le port du serveur de manière dynamique coté client.
- Modification du routeur de gauche pour qu'il effectue le "forward" automatiquement.
30/06/2008, 14h53
tir0nik

merci pour vos réponses et pour ton explication nicroman,

Citation:

Envoyé par nicroman

- Utilisation de UPnP-IGD (non recommandé en raison des failles de sécurité que cela engendre)

je suis allé voir ce que c'était sur wikipedia mais j'ai pas compris grand chose, comment on l'utilise ?

Citation:

Envoyé par nicroman

- Utilisation d'un NAT "conique" du coté gauche... Mais cela demande d'apater le port du serveur de manière dynamique coté client.
Modification du routeur de gauche pour qu'il effectue le "forward" automatiquement.

c'est possible sans que l'utilisateur n'ai à configurer le routeur lui-meme sa ?

Citation:

Envoyé par wiztricks

C'est une question relative aux fonctions de 'pare-feu' du routeur qui peuvent être résolues de différentes façons en fonction de l'équipement.

Tant que tu n'as pas résolu cette question, pas la peine d'aller plus loin.

En fait j'aimerai que sa marche sur tout les routeurs, pas que le programme ne marche qu'avec mon routeur, donc je ne pense pas que se soit spécifique à l'équipement.
30/06/2008, 23h42
zais_ethael

Ecoute, ça n'a absolument rien à voir avec ton application. Le NAT est fait comme ça point barre, si tu veux pouvoir joindre un ordinateur dans un réseau privé il faut configurer une redirection de port sur le routeur (ou une DMZ, ce qui revient grosso-modo au même).

TOUTES les applications sont concernées par ce problème, il ne faut pas chercher longtemps sur Google pour trouver des millions de messages d'utilisateurs qui ne comprennent pas cette dure réalité. Il existe bien deux trois astuces techniques (je me souviens vaguement d'une techno permettant d'ouvrir un port serveur sur un routeur par simulation de demande client et qui, je crois, est utilisé par bitorrent, si quelqu'un s'en souvient...) mais elles sont limite encore plus complexes et restrictives qu'une bonne config de routeur.

Conclusion: si tu veux faire tourner un serveur sur un ordi (et qu'importe que tu l'aies codé toi même) apprends à configurer ton routeur ou attends l'IPv6.
02/07/2008, 21h39
tir0nik

Citation:

(je me souviens vaguement d'une techno permettant d'ouvrir un port serveur sur un routeur par simulation de demande client et qui, je crois, est utilisé par bitorrent, si quelqu'un s'en souvient...)

C'est possible ça ? comment ? il faudrait déjà trouver comment on peut ouvrir un port sur son routeur sans avoir à le configurer manuellement...
02/07/2008, 22h51
ram-0000

Citation:

(je me souviens vaguement d'une techno permettant d'ouvrir un port serveur sur un routeur par simulation de demande client et qui, je crois, est utilisé par bitorrent, si quelqu'un s'en souvient...)

Je crois que tu veux parler de UPnP
03/07/2008, 01h27
zais_ethael

Peut-être, je ne connais pas UPnP. C'était vraiment une bidouille basé sur la conception de certaines tables de NAT (pas toutes) où on envoyait un paquet "dans le vide" pour simuler une demande client afin d'ouvrir un port dans le routeur. Ensuite le vrai client se connectait au serveur en employant le même port. Cela nécessite bien entendu un vrai serveur situé en dehors des deux NAT afin de faire véhiculer les messages nécessaires pour l'ouverture de la connexion, c'est la raison pour laquelle ça me fait penser à bittorrent qui a justement plein de serveurs super gentils pour rendre ce genre de service.

@tir0nik: mais non, oublie, toi tu n'as même pas la contrainte d'un routeur d'entreprise dont l'admin est pas conciliant, c'est un routeur familial avec lequel tu peux faire ce que tu veux. Quand on veut faire serveur on apprend à configurer son routeur.
03/07/2008, 16h34
nicroman
Encore faut-il que le routeur fasse du NAT conique (ce qui est le but de UPnP)...

Normalement le NAT *doit* faire correspondre un tunnel à un autre tunnel, c'est à dire un 4-uple (ip-source-privée,port-source-privée,ip-destination-public,port-destination-public) à un (ip-source-public,port-source-public).
A l'opposé de l'ouverture de port (conique) qui ne se sert que de la partie (ip-source-privée,port-source-privée)

Donc si deux machines sont derriere un NAT classique, aucun moyen de les faire communiquer (sauf à ouvrir des ports 'coniques' sur le routeur à la main, ou par UPnP).

Il y avait une bidouille qui marchait sur 'quelques' routeurs, partant du principe que le routeur allait allouer le port immédiatement supérieur à la demande suivante.... Mais elle demande un serveur-tiers...

Genre:
- A est connecté à S par le tunnel Tas
- B est connecté à S par le tunnel Tbs
- A envoit à S (par une nouveau tunnel za) le fait qu'il veut se connecter à B => le routeur de A fait correspondre (A priv,za) à (A pub,Ax,S,o)
- S recoit la demande de A depuis (A pub, Ax)
- S envoit à B (par Tbs) le fait que A veuille se connecter à lui depuis le port Ax
- B envoit une demande de connection à A avec le port Ax+1 => le routeur de B fait correspondre (B priv, zz) à (B pub,Bx, A pub, Ax+1)
- B envoit à S (par un nouveau tunnel zb) le fait qu'il essaye de répondre à A => le routeur de B fait correspondre (B priv, zb) à (B pub,Bx+1,S,o)
- S recoit la réponse de B depuis (B pub, Bx+1)
- S répond à A qu'il faut utiliser le port Bx
- A essaye de se connecter à B en utilisant le port Bx => le routeur de A fait correspondre (A priv, zz) à (A pub,Ax+1,B pub,Bx)
Et voilà... le deux routeurs on des routes ouvertes
Encore faut-il, pour que celà marche, que les routeurs allouent leurs ports séquentiellement (et tous ne le font heureusement pas !), et avoir un middle-man sans NAT ! :D
03/07/2008, 23h15
zais_ethael

C'est bien pour ça que c'est pas du tout une bonne idée :) Sauf, très éventuellement, dans le peer to peer.