Version imprimable
Bonjour,
Quand je programme des applications clients/serveurs en C#:
- Si le PC qui lance le serveur est directement connecté à Internet, il n'y a aucun problème.
En revanche :
- Si le PC qui lance le serveur est sous un NAT (routeur), le serveur ne fonctionne qu'en local et un client ne peut pas s'y connecté à partir d'internet.
Ma question est la suivante :
Comment faire fonctionner le serveur sur internet même si le PC l'executant est sous un NAT ?
Merci de bien vouloir m'aider
Ce problème arrive dans presque toutes les applications client/serveur notamment Les P2P, j'ai beaucoup rencontré ce problème.
- La solution était de faire un mapping de port c'est-à-dire, dans le programme d'administration de ton NAT vas chercher une option qui te permettra de mapper toute les données qui sont addressées au NAT via le port X (X port de communication de ton app) vers l'adresse IP locale du serveur.
- Une autre solution consiste à mettre ton serveur dans une DMZ (DeMilitarized Zone), cherche dans google.
Je travaille dans une équipe qui fait du P2P, bien que je ne travaille pas sur la partie reseau, je sais que ceux qui y travaille ont eu ce genre de problème.
Pour essayer d'obtenir l'adresse des pc derriere un nat (afin de les faire fonctionner comme serveur) ils ont utilisés des serveur stun pour régler le problème.
Il s'agit la d'un probleme réseau, pas de développement.
Comme ce fut cité, deux voies :
- port mapping
- DMZ (Demilitary zone)
Si ton programme serveur accède à des ressources du LAN qui doivent rester "confidentielles" et "protégées" comme les bases de données, il n'est pas conseillé de mettre le serveur sur une machine dans la DMZ, car dans ce cas, on perd toute utilité d'une DMZ.
Si ton programme serveur se fiche complètement des données hors de la machine sur laquelle il tourne, et que cette machine, n'est pas un serveur de données ou de fichiers, tu peux mettre la machine dans la DMZ sans aucun problème et dans ce cas le port mapping ne sera plus nécessaire.
Attention : Une machine installée dans une DMZ est une machine qui évolue en milieu hostile, en clair elle évolue comme si elle était raccordée directement à internet, même si cela passe par du NAT. Cela signifie que tu dois la munir d'un très bon parefeu intégré et d'un bon antivirus, même si le routeur NAT dispose d'un firewall intégré en amont.
Parfois, et ce n'est pas rare, on trouve meme un routeur NAT, avec la DMZ directement raccordée, et un firewall derriere lequel est situé le LAN.
Cependant meme si le Firewall protége TOUTE l'infrastructure, les machines dans une DMZ sont par définition EXPOSEES contrairement aux autres... il faut donc les protéger.
Il faut donc sur ces machines minimiser les codes inutiles, tout ce qui n'est pas utile ne dois pas etre activé ou lancé ni rien.
Si tu opte pour le port mapping... il ya quand meme quelques règles à respecter, mais elles sont d'ordre conceptuelles, dans ton application.
Lorsque tu communique en client/serveur sans meme le vouloir ou le savoir tu utilise un protocole. Le problème de nos jours c'est que certains protocoles extremement mals fait interdisent le NAT.
si tu veux un exemple, certains protocoles nécessites de faire transiter l'ip du serveur... problème cette IP est locale, et n'a aucun sens dans le net.
Si le client vérifie que l'ip effective qu'il utilise pour connecter le serveur et que l'ip que le serveur retourne sont identique pour s'assurer qu'il n'y a pas spoofing ou usurpation.... CRAC... déconnexion... et oui pas de bol les ip de coincides pas... Si maintenant dans ton serveur tu décide de lui dire que l'ip qui va retourner c'est l'ip publique, qu'a cela ne tienne... déjà quand il va faire ses écoutes, s'il est pas bien concut... il va chercher une ip qu'il ne possède pas et pouf... il écoutera rien du tout, s'il est bien conçut il écoute au bon endroit, et retourne l'ip public dans le protocole...
Mais si maintenant tu te connecte du coté LAN avec le client... l'ip effective est l'ip intranet, et l'ip retournée est la public... CRAC aussi...
En plus tu ne peux pas palier le problème en connectant le serveur en utilisant ton ip publique depuis le client LAN, car un trafic sortant ne peut rerentrer de lui meme... Ainsi de l'intérieur du réseau tu ne peux pas scanner, ou tester l'ip publique de ton réseau, directement.
C'est un peu long, mais de nos jours j'ai vu encore pas mal d'implantations serveurs et clients, qui utilisent la comparaison ip effective et ip théorique comme moyen d'authentification... et ca mene souvent au désastre.
(certains jeux de types mmorpg par exemple utilise ce modele d'authentification pour s'assurer que le serveur est bien ce qu'il prétend etre... et pour d'autres raisons, mais font que le jeux n'est plus accessible soit à l'extérieur, soit à l'intérieur du LAN où est le serveur)
Faux c'est aussi un problème de développement, actuellement des boites font du dev sur le p2p et sont confrontés à ce genre de problème qu'ils doivent surmonter par le code.Citation:
Il s'agit la d'un probleme réseau, pas de développement.
Il y a toujours un moyen de contourner ce problème, surtout en p2p.
Mais son problème est surtout administratif niveau réseau.
Ou au niveau conceptuel coté developpement.
Tot ou tard il faut faire un choix. Le NAT c'est bien mais ca pose des problemes ont le sais, mais il faut aussi que des moyens soient mis en place de part et d'autres des fonctions. Ainsi il faut que les serveurs et les clients soient bien concut, et il faut que l'administrateur réseau fasse le mapping, (ou l'appli peut aller dans la dmz, et là... ba c'est facile)
Lui il a dit que son application fonctionne s'elle n'est pas derrière le NAT, donc on vois clairement que le problème est loin d'être un problème de développement, c'est un problème de réseau et surtout c'est un problème de sécurité posé par le NAT qui est résolvable via les deux solutions déjà exposées.Citation:
Envoyé par ced600
Cela peut aussi montrer qu'il n'a pas gérer le problème potentielle du NAT dans son application et cela peut être résolu par le développement.Citation:
Lui il a dit que son application fonctionne s'elle n'est pas derrière le NAT, donc on vois clairement que le problème est loin d'être un problème de développement, c'est un problème de réseau et surtout c'est un problème de sécurité posé par le NAT qui est résolvable via les deux solutions déjà exposées.
Maintenant je ne connais pas l'environnement sur lequel le soft sera exécuté.
Mais il se peut qu'il ne puisse pas configurer le nat ou demander la configuration du nat. C'est le cas des logiciels P2P, lorsque l'on développe pour le grand publique, on préfère éviter de demander aux clients de configurer leur réseau. On s'arrange pour que le soft fonctionne quoiqu'il se passe (enfin s'il n'y a pas de réseau physique on peut rien faire :) ).
D'où la proposition d'obtenir l'ip de l'adresse entrante telle que peut l'accepter le nat via l'utilisation d'un serveur stun.
il y a quelque chose d'important que j'ai omis de précisé :oops:
c'est que je ne voulais pas toucher à la configuration du routeur.
De plus, j'avais déjà mis le PC lançant le serveur en DMZ et pourtant ça n'a pas marché.
Mais par exemple : quand je lance un le programme serveur dans le PC d'une personne qui partage aussi sa connexion, la communication ne s'établie pas. Pourtant j'arrive à piloter son PC à distance grâce à LogMeIn. Que cela signifie-t-il ? Qu'en réalité la personne et moi même sont client du serveur de LogMeIn ?
Connais tu le fonctionnement d'un NAT ?