Discussion :

[ram-0000]

Comment faire pour rendre mon application (serveur WWW par exemple) visible depuis Internet ?

J'ai entendu parler de translation d'adresse, qu'est ce que c'est, comment cela marche t'il, où est ce que cela se met en place ?

[Christophe]

Explications du NAT

ton poste en local envoie une requête à Internet via la passerelle ( le routeur ou la box )

De l’extérieur, seule l'IP WAN du routeur/box est vue ( le routeur ayant une carte réseau à l’intérieur et une carte réseau à l’extérieur ).

pour qu'une adresse intérieure puisse communiquer avec l’extérieur, le routeur recevant un paquet d'un poste en interne modifie l'adresse source par la sienne, ainsi que le port et garde dans une table de translation ( NAT=Network Translation Table ) , envoie le paquet sur Internet, lors de la réponse de l’extérieur,le paquet est à destination du port X, ce port dans la table destination pointe sur l'ip de ta machine interne, le routeur change donc l'adresse de destination par l'adr ip et le paquet est envoyé vers le réseau interne.

Pour que ton site WEB soit visible de l’extérieur, tu dois donc "natter" ton ip interne port 80 (80=WEB) vers l’extérieur.

Point à prendre en compte : Si ta BOX répond sur le port 80 pour l'administrer, tu risque d'avoir des difficultés. Pour régler ceci tu peux par exemple faire répondre ton serveur Web sur le port 8000 par exemple et tu natte ton ip lan port 8000 vers l'ip wan port 80. De cette façon, quand tru appelles ton ip wan sur le port 80 de l’extérieur ça renvoie sur ton ip lan port 80.

Sur certaines BOX, ça ne fonctionne que si tu natte autre chose que le port 80. ton site répondra sur un autre port que le 80 ce qui impliques que l'URL d'accès doit du type http://adr_site:port

Par ailleurs, si tu comptes lier ton adresse ip à un nom DNS attention, tu n'es pas forcément en ip fixe. Dans ce cas il est possible d'utiliser des services de type DynDNS.

[sevyc64]

Petit détail, mais non des moindres pour ceux qui veulent tester si leur site est correctement accessible depuis l'extérieur en testant depuis l'intérieur. Beaucoup s'y cassent les dents en disant ça marche pas.

Contexte :
- Le site web se trouve sur une machine d'un réseau local (situation classique, même pour un site en production)
- Le test se fait depuis une machine du même réseau local (même machine que le serveur web ou autre machine)
- Le test se fait sur l'url publique du site donc en passant par un DNS public.

Situation :
- Le client (navigateur sur la machine de test) va demander l'url. Il va donc interroger le DNS, obtenir l'adresse IP publique du site, puis interroger cette adresse qui se trouve donc être l'adresse publique de son propre réseau local.
- La requete va donc partir du client, atteindre le routeur de sortie sur internet. Le routeur va donc router la requete vers l'adresse IP publique du site, c'est à dire qu'il va vouloir faire sortir la requete par son interface WAN en direction de .... son interface WAN

Là, gros problème, c'est que l'on appelle un routage en épingle à cheveux (Hairpin). Cette situation pouvant représenter un certain type de corruption d'un réseau local, la plupart des routeurs (c'est également vrai pour les box ADSL) sont configuré par défaut pour ne pas router ce type de requete et les jeter à la poubelle.

Solutions :
- Si l'on dispose d'un routeur compatible (c'est rarement le cas des box ADSL), il faut le configurer pour activer l'option de Hairpin NAT. Ainsi, le routeur ne fera pas sortir ce genre de requete que le réseau public, mais saura la rerouter sur le réseau privé comme si elle arrivait du réseau public
- Si on ne dispose pas routeur compatible, il faut faire le test depuis une machine réellement sur un autre réseau et donc passant par le réseau public internet (donc demander à un voisin, amis, connaissance, etc...).
- Si, malgré tout on veut tester depuis une machine du réseau local il faut utiliser un vpn, ou un système de proxy public anonyme, c'est à dire envoyer la requete à une machine distante sur internet qui va faire le relais en renvoyer la requete au serveur web.

[Christophe]

Je connaissais pas le hairpin NAT.

[ciscowarrior]

Le problème ici vient du fait que le serveur DNS va renvoyer l'adresse publique du serveur, on peut résoudre ce problème de plusieurs façons:
1° créer une entrée dans le fichier hosts de la machine de test qui pointe vers l'IP privée
2° utiliser du split DNS: si la requête provient du même sous-réseau on recevra l'adresse privée du serveur à la requête DNS
3° utiliser la fonction de DNS doctoring ou DNS rewrite si le routeur le supporte, les routeurs Cisco font du DNS rewrite quand ils font du static PAT sur une adresse WAN( pas sur une interface WAN malheureusement), il vont donc changer la réponse du serveur externe(adresse publique) en l'adresse privée.

Si maintenant on n'utilise pas le FQDN pour tester mais uniquement l'adresse publique du serveur depuis le LAN alors on est toujours en face du problème de NAT hairpinning.
Dans ce cas sur un routeur Cisco ilsuffit d'utiliser NAT NVI au lieu du NAT classique,comme dans l'exemple suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
int vlan1
ip add 192.168.1.254 255.255.255.0
ip nat enable
no ip redirect
int dialer 1
description WAN interface
ip address negotiated
no ip redirect
ip nat enable
ip nat source static tcp 192.168.1.1 80 210.12.12.12 80

Alain

[Trebly]

Bonjour,

La discussion #post7706013

Traite une bonne part du problème et donne je pense des idées sur la question.

A bientôt

Trebly