# Site hébergé disponible en externe mais pas en local



## R2.0 (28 Juin 2012)

Bonsoir, 
J'ai un problème j'héberge actuellement un site web sur un serveur jusque là tout va bien.

Sauf que de chez moi l'accès au site se fait sans problème mais dans l'entreprise (là où est le serveur) ce n'est pas le cas,
_en effet lorsque je tape l'ip 82.XXX.XXX.XXX la page n'est pas trouvée alors que sur mon ordinateur à la maison en tapant la meme IP mon site s'affiche._

La redirection du routeur se fait par NAT vers le serveur sur 192.168.11.2 du port 80 vers le port 8080. (apache écoute sur le port 8080 de 192.168.11.2).

Cependant j'ai pu noter que lorsque j'_enleve les redirection NAT_ l'ip 82.XXX.XXX.XXX (depuis le réseau local de l'entreprise) je tombe sur_ l'interface de gestion du routeur_.

Je n'ai trouvé aucun filtrage sortant.

Le routeur est un D-LINK 2640B.


----------



## Polo35230 (29 Juin 2012)

Bonjour,

Je n'ai peut-être pas tout compris, mais pourquoi, en interne, accéder au serveur via l'adresse IP publique?
C'est pour simuler une connexion externe  depuis le Lan du serveur?

Sinon, en interne, ça marchera en utilisant l'adresse IP locale du serveur.

Maintenant, c'est vrai que ça devrait aussi marcher via l'adresse IP publique...
Peut-être essayer en désactivant le firewall du D-Link. Il n'y a pas de box?
Il faudrait aussi regarder dans le log système du D-Link (menu maintenance). Il y aura certainement une indication.


----------



## R2.0 (29 Juin 2012)

En fait sur le site en question il y a une application web, donc le personnel doit pouvoir y acceder .
Comme ce sont des non techniciens, il serait preferable d'utiliser une url plutôt qu'une IP surtout que le site est hebergé sur le port 8080.
(Il reste plus simple a mon avis de taper app.monsite.fr que http://192.168.11.2:8080.)
Mais pour faire cela l'ip publique doit renvoyer sur la bonne IP privée même en local.

Meme une fois le firewall du D-LINK désactivé ça ne fonctionne toujours pas.

Non il n'y a pas de box, juste ce routeur.
Je ne vois rien de spécial dans le journal.


----------



## Polo35230 (29 Juin 2012)

R2.0 a dit:


> (Il reste plus simple a mon avis de taper app.monsite.fr que http://192.168.11.2:8080.)
> Mais pour faire cela l'ip publique doit renvoyer sur la bonne IP privée même en local.



C'est vrai...
Vous utilisez donc (pour les connexions venant de l'extérieur) un service du genre DynDns, et vous voudriez que ça marche aussi pour un appel venant de l'intérieur?


----------



## R2.0 (29 Juin 2012)

Polo35230 a dit:


> C'est vrai...
> Vous utilisez donc (pour les connexions venant de l'extérieur) un service du genre DynDns, et vous voudriez que ça marche aussi pour un appel venant de l'intérieur?



Pour les connexions de l'extérieures, j'ai un nom de domaine redirigé vers l'IP publique.
Une redirection NAT de l'ip publique (port 80) vers le serveur (port 8080).

Effectivement nous voulons que ça marche aussi pour des appels venant de l'interieur.


----------



## Polo35230 (29 Juin 2012)

Alors oui, ça devrait marcher avec un nom de domaine référencé.
En local, la commande "nslookup app.monsite.fr" marche?

Pour un serveur DNS qui reçoit la requête, en fct de son origine (de l'extérieur ou du Lan du serveur), je ne vois qu'une différence, c'est dans le couple adresse IP source et adresse IP destination.
-Dans le 1er cas, l'adresse IP source est différente de l'adresse IP destination.
-Dans le 2ème cas, c'est la même en source et en destination. (c'est l'adresse IP publique côté serveur)
Je ne suis pas un spécialiste des serveurs DNS, mais c'est peut-être ça qui gène...

Il y a aussi la solution de mettre un serveur DNS sur site pour gérer les appels internes.

On peut aussi renseigner dans les machines du Lan (côté serveur) les fichiers hosts.
C'est pas très beau, mais ça peut se faire...


----------



## R2.0 (2 Juillet 2012)

Polo35230 a dit:


> Alors oui, ça devrait marcher avec un nom de domaine référencé.
> En local, la commande "nslookup app.monsite.fr" marche?



oui ça marche...
nslookup www.monSite.fr
Server:		192.168.11.1
Address:	192.168.11.1#53

Non-authoritative answer:
Name:	www.monSite.fr
Address: 82.XXX.XXX.XX (Adresse OK)

nslookup 82.XXX.XXX.XX
Server:		192.168.11.1
Address:	192.168.11.1#53

Non-authoritative answer:
XX.XXX.XXX.82.in-addr.arpa	name = LDijon-XXX-XX-XX-XX.w82-XXX.abo.FAI.fr.

Authoritative answers can be found from:

;




> Il y a aussi la solution de mettre un serveur DNS sur site pour gérer les appels
> On peut aussi renseigner dans les machines du Lan (côté serveur) les fichiers hosts.
> C'est pas très beau, mais ça peut se faire...



Malheureusement, il n'est pas possible de specifier un port dans un fichier hosts.

//------------------------------------------------------------------

Finalement il y a du nouveau :
J'ai changé le type d'informations noté dans les logs vendredi et il se trouve qu'aujourd'hui, je trouve à plusieurs reprises dans le log :
_"dnsprobe[693]: dns query failed"_

Du coup je pense que le problème pourrait venir de là.
La configuration du DNS est actuellement en automatique, alors je ne comprends pas vraiment d'où cela pourrait venir.


----------



## Polo35230 (2 Juillet 2012)

R2.0 a dit:


> Malheureusement, il n'est pas possible de specifier un port dans un fichier hosts.


C'est vrai, mais c'est mieux...
Le fichier hosts est utilisé par la couche IP (adresse IP), mais pas par la couche TCP (n° de ports).
C'est l'application, ou le service qui renseignera le n° de port.

Donc, si dans le ficher hosts, si on rajoute une ligne  82.x.y.z  monsite.fr, vous pouvez , par exemple:
Taper la commande "ftp monsite.fr". Il n'y aura pas de requête DNS (le fichier hosts est consulté en premier), et l'ouverture de session se fera bien sur le port 21 (ftp)
Taper une commande "telnet monsite.fr". Le port 23 sera alors utilisé.
Dans la barre de de navigation, taper "monsite.fr". Le port 80 sera alors utilisé.
https://monsite.fr  (port 443)
monsite.fr:8080  pour utiliser le port 8080 (au lieu du 80 par défaut).
Et ainsi de suite.





R2.0 a dit:


> Finalement il y a du nouveau :
> J'ai changé le type d'informations noté dans les logs vendredi et il se trouve qu'aujourd'hui, je trouve à plusieurs reprises dans le log :
> _"dnsprobe[693]: dns query failed"_
> 
> ...



Alors, la requête dns (à partir du lan du serveur) marche. C'est bien l'adresse IP publique en 82.x.y.z qui est retournée.
Je pense que le pb n'est pas au niveau DNS.

Je pense plutôt qu'après avoir reçu la réponse à la requête DNS, le navigateur va tenter d'ouvrir une session TCP avec comme adresse destination 82.x.y.z (adresse publique de la box).
C'est donc (pour la box) comme un appel sortant. Sauf que là, ça ne sort pas sur internet, parce que cette adresse correspond à l'adresse wan de la box. Pour la box, ce n'est donc pas un appel entrant, et je crois que dans ce cas là, elle ne natera pas l'adresse 82.x.y.z en l'adresse locale du serveur (en 192). Contrairement à un appel venant d'internet.
Pour moi, ça ne marchera pas.
Pour mettre le pb en évidence, sur un mac qui tente de se connecter au serveur (en interne), il faudrait faire un sudo tcpdump host 82.x.y.z 
Je pense qu'on verra alors uniquement un demande d'ouverture de session (tcp syn), mais pas la réponse (tcp syn ack) qui va ser perdre dans la box.
Enfin, je crois...

Pour l'erreur dnsprobe 693, il faudrait faire un essai, et s'assurer que c'est pas dû à des essais antérieurs...


----------



## R2.0 (2 Juillet 2012)

Je ne sais pourquoi mon message precèdent est soumis à moderation (peut-être trop long).
Alors désolé pour le flood.

La commande retourne 2 types de lignes

7 fois :
13:35:52.139136 IP 192.168.11.208.53331 > ldijon-xxx-xx-xx-xx.w82-xxx.abo.wanadoo.fr.http: Flags , seq 1193233987, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 860181860 ecr 0,sackOK,eol], length 0

puis 6 fois :

13:35:54.749197 IP 192.168.11.208.53328 > ldijon-xx-xx-xx-xx.w82-xxx.abo.wanadoo.fr.http: Flags , seq 4140870617, win 65535, options [mss 1460,sackOK,eol], length 0

13 packets captured
165 packets received by filter
0 packets dropped by kernel


----------



## sparo (2 Juillet 2012)

Problème classique ....
Je récapitule tu as fait un serveur web en local et tu rediriges le port 80 de ta livebox (d'après le dernier log tu es chez orange) sur ce serveur web. De l'extérieur tt va bien mais de l'intérieur dur réseau c impossible

Et bien ce que tu veux faire s'appelle du "loopback" c'est à dire une demande venant du réseau interne qui doit revenir vers lui même .... Et malheureusent certains routeur dont les livebox ne save pas faire ce genre d'operation .....

Il te reste 2 options :
- le fichiers hosts
- balancer la livebox ou le routeur de merde et acheter un truc qui marche


----------



## Polo35230 (2 Juillet 2012)

La trace confirme ce que je pensais.
La requête DNS s'est bien passée (on ne la voit pas parce qu'on filtre la trace uniquement sur l'IP publique).

Le navigateur essaye d'ouvrir une session TCP (c'est le "Flags ") sur l'adresse IP publique de la box, port 80(ldijon-xxx-xx-xx-xx.w82-xxx.abo.wanadoo.fr.http)
L'adresse IP destination est interprétée. (pour voir les adresses non interprétées, il faut rajouter -n dans la commande).
Il y a 7 tentatives, toutes infructueuses...
Le navigateur refait ensuite 6 tentatives sur les mêmes adresses, mais en enlevant certaines options TCP, mais là aussi, il y a échec.

Quand ça fonctionne, une ouverture de session TCP entre deux machines se passe en trois phases:
AdresseIPmachine1---> AdresseIPmachine2   TCP SYN (Flags )
AdresseIPmachine2---> AdresseIPmachine1   SYN ACK (Flags [S.])
AdresseIPmachine1---> AdresseIPmachine2   ACK (Flags [.])

Sur la trace, il n'y a que la phase1, mais 13 fois. C'est pas faute d'avoir essayé...
La box devrait renvoyer le SYN Ack, mais elle ne le fait pas. Et je pense que c'est normal. C'est un cas de figure tordu. On essaye d'accéder à une machine du réseau local en sortant sur internet...
Chaque TCP SYN est envoyé vers la box qui devrait remplacer l'adresse publique par l'adresse privée. Elle ne le fait pas parce que ce n'est pas un appel entrant.

Pour que ça puisse marcher, il faudrait un firewall (devant la box) qui fasse le boulot.

Mais le mieux, c'est un serveur DNS local, ou l'utilisation du fichier hosts.

Confirmé par spao 

---------- Nouveau message ajouté à 15h52 ---------- Le message précédent a été envoyé à 15h44 ----------




sparo a dit:


> Il te reste 2 options :
> - le fichiers hosts
> - balancer la livebox ou le routeur de merde et acheter un truc qui marche




C'est vrai qu'on a parfois envie de balancer la box, mais malheureusement, c'est de plus en plus difficile de la supprimer (pour un particulier, s'entend) à cause des différents services associés (TV, Tel,...)


----------



## sparo (2 Juillet 2012)

si tu veux garder ta box alors il te suffit de rajouter un firewall/wifi digne de ce nom en DMZ derrière la box comme cela tu aura la beurre et l'argent du beurre et en plus un Wifi qui marche correctement


----------



## R2.0 (3 Juillet 2012)

C'est bien ce que je pensais, merci à vous.

Pour le firewall je vais me renseigner.


----------

