Situation :
 
XP Pro patché SP1 et dernières maj windows
IIS de windws
un site web à 3 frs (3 pages, histoire de tester)
un MODEM speedtouch home ethernet
 
 
==> tout marche, tt le monde accède au server web configuré par défaut sur le port 80.  
 
 
Manipulation :
 
SpeedTouch HOME => PRO
 
Routage des ports 80, 20, 21, et autres bricoles vers mon pc (10.0.0.1) comme indiqué sur Forpage.com  
 
Résultat :
 
Le serveur FTP roxxe tout, les autres aussi, SAUF le serveur HTTP qui reste inaccessible
 
Par contre le serveur HTTP est accessible sans probleme sur le Lan, mais ça j'm'en fous un peu
 
 
Des idées ? J'ai oublié une bricole ? Dans la config du server http ? config du routeur ?  
Faut-il router en TCP ou en UDP ? j'ai testé les deux et rien mais bon, on peut toujours refaire au besoin
 
 
Merci d'avance  

serveur web = port TCP 80, donc, normalement c'est bon.
ton serveur WEB, il est bien sur le 80 ?
deplace ton FTP sur le 80 pour tester si le 80 est bien ouvert, si ton FTP marche avec le 80, le prb est donc sur la configuration de ton serveur web.

pas bete

c'est bon j'ai testé, tout marche bien mais en fait le truc chelou, c'est que :  
http://mon.ip ==> marche pas à partir du server, mais ça marche à partir d'un autre pc dans le world.  
 
pareil pour le ftp
 
donc en fait pas de probleme

t'entends quoi par mon ip ? si c est ton ip local oui ca marchera normalement, si c est ton ip wan ca doit marcher si t'es derriere un routeur.

internet == routeur == hub == monpc
 
http://ledrien.Ath.cx : ça redirige vers l'ip attribuée par mon FAI (ip wan je suppose) et ça marche pas !  
http://localhost ou 127.0.0.1 ou 10.0.0.1 ben ça marche
 
bon, c déjà mieux qu'avant ou rien ne marchait et pis yavait http://ledrien.ath.cx qui me donnait les pages web de config du routeur

si tu veux que ca marche avec ton nom de domaine, il faut mettre ton nom de domaine dans le fichier HOSTS.
 
127.0.0.1 ledrien.Ath.cx

euh, ui, c'est la solution bricolage, mais j'aimerais bien savoir pkoi ça marche pas quand je tape "http://mon.ip.wan"  
 
sinon tu as une bonne solution de remplacement en effet

ben normalement ça fait :  
PC  : "envoie http://ledrien.ath.cx"
STP : "3 sec je cherche"
STP : "c'est moi cette ip, je regarde dans la table nat"
STP : "c'est toi le serveur, donc vas donc chercher ça sur ton port 80 !"
PC  : "bien compris"
 
en gros, non ?

surtout ke kan je " ping ledrien.ath.cx " ben il me sors des tps de 1ms

C'est pas du bricolage, a moins que t'esun serveur DNS en local c'est ainsi qu'il faut faire, il faut mettre son nom de domaine dans le fichier HOSTS, c'est comme que c se se passe et ca n'a rien avoir avec une bidouille.
 
quand tu ping c'est pas un souci c'est ton routeur qui repond.
essai de pinguer sur ton ip local tu verras c'est possible.
 
par contre la ton routeur fait une redirection du port 80, en gros tu envois une requete avec ton ip locale sur le port 80, le routeur voit la requete il envoit ca sur le net (avant y a eu la resolution du nom de domaine, maintenat il fait la requete avec ton ip) ca passe un autre routeur sur le net, ce routeur reroute sur toi vu que c'est toi , ton routeur voit une deuxieme fois la MEME requete, celle meme qu'il vient d'envoyer, y se dit pas con l'asticot , doit y avoir un probleme, je vais pas envoyer une donnees quelque part pour qu elle me revienne intact c'est trop con , alors il supprime le paquet, ca evite les boucles inutiles.
 
y a peut etre une autre explication car pour eviter les boucles c'est le TTL qui est utilise normalement, mais je crois que le routeur est pas con au point de forwarder un paquet qu'il vient lui meme d'envoyer.

 
NON <- en gros
 
Faut pas chercher... le NAT en interne ne marche pas
 
le dialogue dns va juste donner çà :
 
PC  : "envoie http://ledrien.ath.cx"
STP : "ip publique"
 
ensuite la demande http:
 
PC : ip_publique:80
 
A partir de là le routeur devrait faire la translation NAT, mais cela ne se fait pas car le poste est du côté lan... maintenant savoir ou çà bloque    
 
la seule solution, le fichier host ou un dns avec une zone configurée en interne... çà marche nickel  
 
edit : clark kent explique bien    grilled

oki, je pige mieux merci
 
jvais faire joujou 30 sec avec le fichier hosts

enfin bon mon explication est peut etre conne, car ton routeur sait tres bien que l ip que tu essais de joindre c'est lui, alors a mon avis il envoit tout simplement pas la requete etsupprime le paquet sans se poser de question.
 
pour ce qui est du ping, je pense que le routeur repond comme un ane, il sait que c'est lui et renvoi la reponse, tant dis que dans le cas du http il peut evidement pas te repondre car il ne possede pas ce service. et pour le routage NAT il faut que tu lui causes de l'exterieur.
 
bon va falloir que je demande ce qui se passe exactement dans un routeur a un prof s'il s amuse quand meme a forwarder le paquet (ce qui en fait m'etonnerait) s'il sait que c'est lui.

ce qui bloque c'est le routeur , mais je ne sais pas sil bloque car il voit sa propre requete repasser par la ou s'il ne peut tout betement pas repondre a une requete HTTP sur lui meme , enfin j'en sais rien je crois que linux m'a pertubé .

Pourquoi le ping fonctionne et pas l'accès au serveur web ?
 
Pour la simple et bonne raison que le port forwarding n'intervient pas pour le ping, le routage fonctionnant correctement, tout fonctionne normallement
 
 
Le port forwarding est visiblement activé sur le routeur uniquement pour les paquet provenant de l'extérieur, pour un paquet provenant de l'intérieur, le routeur N'APPLIQUE PAS la règle de port forwarding.
 
Les 2 solutions que je vois :
- modifier la configuration du routeur pour activer le port forwaring également pour ce qui provient de l'intérieur (ce qui m'étonnerait, le speed touch étant assez rudimentaire pour les fonctionnalités de routing)
- comme ça a déjà été dit : résoudre en local ton ip (le + simple étant avec le fichier hosts)
 
La résolution locale étant la + logique, il est en effet abérrant de faire passer par l'interface wan du routeur les paquets ayant pour source et cible des machine de ton lan. Le port forwarding et toutes les fonctionnalités liées à la translation de port/d'adresse ne doivent intervenir que pour les paquets allant d'un réseau à un autre !