Discussion :

[ram-0000]

Pourquoi n'est-il pas possible depuis le réseau interne d'utiliser l'adresse publique pour se connecter à un service ou une machine du réseau interne alors que de la translation d'adresse (NAT) est mise en place ?

[sevyc64]

C'est une question ?

Ça s'appelle le NAT Hairpinning, ou appelé aussi communément la problématique des paquets sortants/ré-entrant.

Le fait d'utiliser l'adresse publique d'un réseau local, depuis ce réseau local pour accéder à une autre machine ou service de ce même réseau local signifie que le paquet en question va partir du client, puisque la destination est une adresse n'appartenant pas au réseau local, il va transiter par la passerelle. Cette passerelle aura pour rôle de diriger le paquet sur le réseau public à destination ..... d'elle même puisque l'adresse de destination est en réalité son adresse publique.

C'est ce phénomène qui pose problème, le paquet qui est censé sortir pour immédiatement ré-entrer.

Pour des raisons que je suis encore incapable de développer (pas assez calé en la matière), la plupart des routeurs (et donc de passerelle) ne routent pas ce genre de paquet par défaut car cela peut traduire un problème de sécurité et de compromission d réseau local. C'est le cas notamment des box adsl en France.

Contrairement au dites box ou il n'est pas prévus de pouvoir configurer cela, certains routeurs évolués permettent de configurer et autoriser ce genre de cas.



Solutions possibles dans le cas de box ADSL ou de routeurs ne permettant pas la configuration, il faut court-circuiter les DNS public qui renvoient l'adresse publique du domaine/service :
- Si on dispose un serveur DNS sur le réseau local, ce serveur doit être le serveur par défaut des machines du réseau local. Il faut créer une entrée dans ce serveur qui associe le domaine/service demandé à l'adresse ip locale de ce service
- En l'absence de serveur DNS local, il faut renseigner le fichier host de chaque machine pour entrer la correspondance service/ip locale.

[ram-0000]

C'est une question ?

Oui, pour la FAQ
cf http://www.developpez.net/forums/d13...brique-reseau/

J'ai posé la question (pour initier le mouvement), tu as commencé à y répondre !

[Trebly]

Bonsoir,

Oui cela s'appelle le "hairpinning" ou "NAT LoopBack".
Il est je pense intéressant de voir les enjeux et les problèmes posés par son implémentation directe ou par pseudo process visant à diriger la requête de manière interne avant qu'elle n'atteigne le "routeur Wan s'il ne sait pas faire"

Ça s'appelle le NAT Hairpinning, ou appelé aussi communément la problématique des paquets sortants/ré-entrant.

Donc autre nom courant est le "NAT Loopback" (ça c'est pour les moteurs...)

Bien d'accord sur l'explication, ici je vais tenter de relancer la discussion pratique tout en cherchant à poser le problème de fond tel que je le vois.

Le besoin essentiel correspond à l'enjeu qui est, pour beaucoup de développeurs, de "dématérialiser" (rendre indépendant de leur configuration "physique" machines et lieu - hors soft- leur process leur développement), je m'explique :

• Développer en réseau local (plus ou moins segmenté) directement sur un répertoire contenant le site et le serveur Web (Apache) et de fichiers destinés au développement (le plus souvent géré avec l'aide de SVN ou GIT) c''est :
• Pouvoir lancer les url utiles depuis le navigateur de la machine de développement (et gérer des recaps ou guide écrits directement en html pour la réalisation de démonstrations ou, autre moyen des "Marque pages partageables (via Xmarks par exemple).
• Obtenir ainsi exactement localement le même process d'exécution que celui de n'importe quel utilisateur externe (avec quelques précautions)
• permettre qu'un futur utilisateur ou un co-développeur puisse dans les secondes qui suivent une modification voir le résultat en utilisant les mêmes url depuis n'importe où.
• Pouvoir se déplacer avec sa machine de développement et continuer à travailler exactement dans les mêmes conditions qu'au bureau
• Le tout dans des conditions de sécurité maximales

Installer le serveur sur le réseau local est alors :

Le fait d'utiliser l'adresse publique d'un réseau local, depuis ce réseau local pour accéder à une autre machine ou service de ce même réseau local signifie que le paquet en question va partir du client, puisque la destination est une adresse n'appartenant pas au réseau local, il va transiter par la passerelle. Cette passerelle aura pour rôle de diriger le paquet sur le réseau public à destination ..... d'elle même puisque l'adresse de destination est en réalité son adresse publique.

Contrairement à ce que tu affirmes il ne me semble pas que ce soit une majorité de routeurs (voici pour info un lien vers une liste, site en anglais :http://opensimulator.org/wiki/NAT_Loopback_Routers.
Par contre dès que l'on ajoute le modem et que l'on considère une "box" le problème se gâte (peut-être plus en France qu'ailleurs ?).

Ma config et process habituel
Pour ma part j'ai de la chance avec une FreeBox évolution je n'ai eu aucun problème (elle fait de plus tout à 1Gb). Le NAT loopback fonctionne parfaitement et les sécurités correspondent à celles des meilleurs matériels (comme il n'y a que 4 ports dont le réseau télé, je développe à domicile,pour les matériels lents j'ai mis un switch Netgear à 1Gb derrière le routeur). Aucun problème avec les divers serveurs et le réseau local multimédia, un plaisir de travailler avec ce matériel. Nota : Je n'ai aucun lien avec Free, mais quand on est satisfait autant le dire.

Un changement temporaire géographique et de matériel (modem-routeur)
Par contre actuellement en déplacement plusieurs mois, j'ai consacré plus de 100h de boulot sans bon résultat pour faire du hairpinning sans fichiers hosts.
Tout cela pour ne pas modifier l'environnement des machines (déplacées), et une mise en service correcte sécurisée : développement Web avec 1 machine + 2 machines de test + 1 serveur, le tout derrière une Livebox 2 (Orange modèle Sagem).

Ceci pour les différentes raisons que je ne détaille pas complètement ici (je sus déja très long) et à l'heure actuelle je n'ai pas trouvé de solution valide autre que l'utilisation de fichiers hosts (avec beaucoup de contraintes évidemment).

Dans ce deuxième cas d’installation j'ai donc a disposition une LiveBox 2 (Orange), et comme son routeur DHCP est essentiellement conçu pour distribuer le Web (d'une lenteur désespérante en réseau local - il ne faut pas espérer construire un réseau local sans mettre derrière un "vrai" routeur derrière en l'occurence un "vieux" Netgear WGR614v7).

J'ai rencontré deux problèmes majeurs :

• Le firewall externe général et son comportement cohérent avec les firewall locaux.
• Essais infructueux de traitement des adresses IP pour envoyer des réquêtes HTTP correctes au serveur
• La nécessite pour raisons de sécurité de deux cartes d'accès réseaux du serveur.

Deux cartes = sécurité avec un NAT
Pour des raisons de sécurité avec cette config il n'était pas envisageable de ne pas avoir, pour le serveur, deux cartes :
- l'un pour le Lan avec un firewall local par machine derrière celui de la liveBox et celui du routeur local Netgear.
- l'autre avec niveau maximal de sécurité derrière le NAT de la liveBox (avec transfert de port pour chaque serveur - Apache, FireFtp, Smtp, LDap ++)

Je n'ai pour l'instant réussi, dès le départ d'ailleurs qu'en utilisant les fichiers hosts.


Au niveau des connaissances je n'en connaissais pas beaucoup plus que sevyc64 :
Quelques principes de bases du NAT LoopBack (hairpinning) et les problèmes essentiels
Pour faire du LoopBack il faut que si l'adresse IP du destinataire retournée par la DNS (distante ou proxy de la box) accepte de traiter le cas où les deux adresses sont identiques. C'est délicat et il faut l'avoir prévu, beaucoup de concepteurs de matériels ne l'on pas fait surtout au début (il y a dix ou quinze ans) et on hérite de la situation.
Donc dans ce cas, si les adresses (Aller-Retour) sont identiques on va chercher s'il y a une règle NAT et soumettre la requête sur ce chemin (tout autre est évidemment interdit), si le serveur répond alors le chemin est créé par le firewall comme avec une adresse externe.
Il n'y a aucun danger particulier mais il faut que les options du NAT fonctionnent, car le serveur va répondre et il faut retourner le paquet, alors le firewall doit être au courant... et continuer à assurer la sécurité.
Le port ouvert va directement et uniquement vers le serveur concerné (Apache en particulier) et le serveur fait le ménage et quand il répond il faut réentrer.
Faire en sorte que le firewall principal du routeur + du serveur fonctionnent bien, permettent d'avoir des traces, bien les utiliser. Nécessite un outil principal le modem-routeur performant et ça c'est du boulot pour le constructeur.

Alors quelles voies explorer et développer pour faire "tout ça proprement et sans danger" :

• Avoir de bon matériel, mais ce n'est pas toujours possible
• Utiliser l'architecture que suggère sevyc64 et dont je décris un déclinaison, améliorée pour faire du pseudo "hairpinning" mais qui ne fonctionne pas encore...

Solutions possibles dans le cas de box ADSL ou de routeurs ne permettant pas la configuration, il faut court-circuiter les DNS public qui renvoient l'adresse publique du domaine/service :

Bien d'accord, pour cela hosts fait bien sont travail sur la DNS machine en ajoutant l'IP locale précisée dans le hosts de la machine de départ, dans l'en tête http soumis au routeur local.
On peut penser a utiliser une DNS locale (à déclarer comme prioritaire dans le routeur local) qui ferait le même travail (en évitant de multiples hosts), mais compléter en en-tête http n'est pas vraiment le travail pur de DNS..

La est ma question principale, puisque ce texte en sous-tend de nombreuses, si par ailleurs je n'ai as dit de bêtises, quand un serveur DNS joue son rôle "complet" il peut ajouter les "poissons pilotes (IP)" du paquet.
J'ai essayé d'installer DualServer (sur sf), j'ai échoué, il faudrait en fait semble-t-il le paramétrer en "DNS-proxy" semble-t-il. Dans ce cas le serveur ajoute l'adresse IP, dans d'autres cas il la substitue en tout ou partie, et ça ça ne marche pas. J'explique.

Le problème des adresses
Des solutions qui apparaissent aujourd'hui simplificatrices ont parfois été adoptés et aujourd'hui rendent le problème infernal car incompatibles avec d'autres options, elle supposaient "une IP"= "un host" ce qui est devenu faux, je m'explique :

• A l'origine "adresse IPv4" ="serveur + son service". C'est la cas des hosts avec Apache les VitualHosts" pas IP <un "ServerName> = <une IP>. Les DNS remplaçant les noms par les IP tout fonctionne... Situation il y plus de dix ans.
• Aujourd'hui le plupart des documents font état de
  "une IP => plusieurs Hosts"
  Avec Apache (2.4 dès 1.7 je crois) l'utilisation des VirtualHost par nom lui permettent d'écouter un seul port ou IP+port pour servir des dizaines de sites qui ont un ServerName "url". Apache va chercher à rapprocher l'en tête de requête avec le ServerName. En cas d'échec on prend tout de même le premier (qui doit par défaut servir à signaler le problème...)
• C'est en fait l'union Proxy+DNS qui fonctionne. Les DNS pures renvoient name->IP et si l'on oublie de traiter le reste de l'en tête HTTP, là plus rien ne marche, le DNS qui peut marcher doit simplement ajouter l'IP à l'en-tête http (mode Proxy-DNS)

Eh! bien c'est ce que fait le traitement local de "hosts" traduit, Apache en VirtualHost par nom sera compatible.

Apache permet aussi d'utiliser les ports pour diriger les requêtes, il faut le voir comme un outil soit de dépannage soit un outil de gestion de charge qui permet via les NAT d'adresser de manière changeante divers serveurs à partir de la même url.

Pour l'instant je n'ai pas trouvé la solution "proxy-dns" à installer localement.

Désolé pour la longueur, j'en ai peut-être trop expliqué trop en détail ?
Mais alors que j'avais précédemment utilisé les hosts, qu’ensuite (dix ans) tout s'est toujours trouvé passer comme un lettre à la poste, j'ai voulu tenter de résoudre le problème avec de matériel primitif et pour l'instant j'ai, j'espère seulement provisoirement, échoué.

Ce qui est étonnant est que mon problème se soit posé à quelques jours près après le header de ce thread par RAM-0000

Cordialement

Trebly

[sevyc64]

Contrairement à ce que tu affirmes il ne me semble pas que ce soit une majorité de routeurs (voici pour info un lien vers une liste, site en anglais :http://opensimulator.org/wiki/NAT_Loopback_Routers.
Par contre dès que l'on ajoute le modem et que l'on considère une "box" le problème se gâte (peut-être plus en France qu'ailleurs ?).

Oui, des différentes infos que j'ai pu glaner au fil du temps, toutes les box ADSL actuelles françaises bloquent normalement le hairpinning. Ce n'est pas forcément le cas, parait-il de modèle plus anciens, Livebox notamment.
Pour ce qui est des routeurs je sais que certains le bloquent, il est possible que tous ne le font pas. Il est probable aussi que des modèles plus évolués, plus "professionnels" permettent de configurer cela.

Pour ma part j'ai de la chance avec une FreeBox évolution je n'ai eu aucun problème (elle fait de plus tout à 1Gb). Le NAT loopback fonctionne parfaitement

Es-tu vraiment sur ???

Lorsque j'avais commencé à m’intéresser au problème, j'avais eu confirmation d'un technicien Free que justement toutes les Freebox sans exception, depuis la première version, y compris la nouvelle à venir à l'époque (la v6 qui n'était pas encore sortie) bloquaient justement le hairpinning.
De ce que tu dis toi, c'est que ta freebox ne le bloquerait pas ?
Perso, la mienne le bloque bien, mais j'ai encore une v4.

[Trebly]

Bonjour,

Un problème de fonctionnalité ou un "blocage"
La première question à laquelle on devrait répondre dans ce sujet :

• S'agit-t-il d'un blocage
• ou bien d'une fonctionnalité manquante

pour ma part je pencherai, ce qui est sous-entendu dans ma réponse précédente pour un problème de fonctionnalité (qui touche en particulier le mécanisme du firewall).

Les systèmes sont écrits pour gérer l'échange :

Code :

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

1
2
3
4
5
6
add-émetteur_local + destinataire externe (add destinataire) 
->add-local_passerelle (add-émetteur_local + destinataire externe)
-> add-passerelle_externe 
-> DNS-proxy ..... réseau ( add-passerelle_externe + requête externe) 
-> retour vers add-passerelle_externe de add destinataire
-> envoi par le passerelle du paquet retour vers add-émetteur_local en récupérant l'adresse locale d'émetteur de requête

que faut-il faire si on remplace "add destinataire" par "add-passerelle externe" et que on doit envoyer la requête non vers l'émetteur mais vers le serveur... puis du serveur vers add-émetteur_local. Ce n'est pas du tout le même travail.
On voit bien qu'il y a un double échange à gérer et qu'il faut bien boucler localement en se servant de la DNS-proxy de la box qui doit "savoir" gérer.

Pour ce qui est de la FreeBox, je crois pouvoir être catégorique :

• Tracert : donne bien en noeud sortant la Freebox elle-même et ne va pas plus loin
• Le paquet est bien reçu par le serveur sur le port déclaré du NAT.
• Pour construire mes requêtes les url correspondent à des sous domaines qui sont des cnames (d'un dynHost) déclarés sur mon hébergeur de domaine (si mon adresse de passerelle n'est pas fixe c'est "DirectUpdate" qui fait la mise à jour, avec free je suis en IP fixe avec Orange ça bouge tout le temps mais DirectUpdate fait très bien son travail).
• Dès qu'un CNAME nouveau est enregistré et qu'il lui correspond dans Apache ou <ServerName> ou un <ServerAlias> lu correspond ça peut démarrer, si et seulement si.

Ca c'est le propre et la simplicité "apparente" du NAT hairpinning.

A noter que plusieurs enregistrements NAT apparaissent avec comme client svchost sur des ports "flottants". Je ne les ai pas détricotés, mais j'en ai cherché l'origine (sécurité oblige) et seule la box semble bien discuter avec le serveur avec des protocoles de paramétrage à distance... permettant une configuration NAT loopback : à confirmer par un vrai expert.

Les problèmes à faire avancer à mon sens :

• Quelle solution pour un DNS-proxy (installé sur le serveur) qui déclaré comme DNS (dns-proxy) principale sur le routeur secondaire fasse le même travail ?
• La configuration modem_routeur+routeur à adopter suivant les vraies possibilités de chacun (exemple; si le modem_routeur peut être mis en mode bridge et que le secondaire est capable de hair-pinning tout devrait marcher mais sans la sécurité de sous-réseaux séparés...)
• Quelles règles des différents firewall pour une sécurité optimale ?

A mon sens on devrait pouvoir donner ici, à ceux qui rencontrent le problème (cf. les objectifs et services associés), des liens utiles, s'ils existent et des solutions.

A noter qu'évidemment j'ai fait passer mes réseaux au test de "nmap".

A plus

Trebly

[Trebly]

Bonjour,

Pour info, la Norme IETF est la RFC 4787 IETF RFC 4787.

Pour la FreeBox je suis moins catégorique, quoique ? Je m'explique (ça peut être très utile).

Les adresses URL gérées localement font l'objet de définition de DynHost et CNAME(s) sur le site hébergeur (j'ai un hébergement, mais il n'y a pas d'outils de débug. Donc OK, et encore des pb de niveau d'outils Php, Mysql. Donc la solution permettant un développement interactif est un serveur de développement à coté de soi. Donc mon serveur local est un appendice défini par un DynHost chez mon hébergeur).

Donc, des CNAME renvoient à une adresse (différente) vers ma Box via un DynHost qui pointe vers mon IP fixe (Free - ceci étant ça marche aussi en dynamique avec sur le serveur DirectUpdate V4).

En local sur la Box j'ai défini un NAT qui effectue une translation de port (sécurité) et redirige les flux http 80 vers le serveur adapté (Apache).
Sur le serveur, Apache écoute le port concerné (d'autres serveurs écoutent d'autres ports).
En fonction de l'adresse d'origine (qui est dans l'en tête http) les virtualHost dirigent la requête vers l'application adéquate (j'en ai une quarantaine) .

On pourrait considérer qu'il n'y a pas de Hairpinning puisque l'url principale change (pas le même sous-domaine). Pourtant grâce au proxy de la Free tout se passe "comme si", puisque la requête (tracert) ne sort pas vers le net et que le fonctionnement résultant est celui défini dans la norme IETF.
Par contre avec une liveBox je n'ai pas réussi : je perds l'adresse d'origine qui est dans le header http et Apache répond avec le VirtualHost (message par défaut générique signalant l'erreur) associé à l'url définie dans le DynHost et non celle d'origine. L'analyse de l'adresse url du bloc n'est donc pas correcte (capable de cette redirection de type Hairpinning).
Pourtant lors d'une requête externe, la translation a tout autant lieu url_origine->url_du dynhost +IP fixe -> Box -> NAT -> Apache. La par défaut d'outil d'analyse, j'y perd mon latin, le problème serait donc le proxy interne de la Box qui fait du bon travail avec la FreeBox mais pas avec la LiveBox (basique).

A noter que aucun fournisseur d'accès n'a répondu à ma question. Et compte tenu de l'échec sur l'installation (déplacement temporaire du poste "4 machines" de développement en province avec un accès Orange) avec la LiveBox, je reste bloqué dans mon travail. Il s'est avéré impossible de définir une configuration à la fois fiable et facile à maintenir. Par contre l'impossibilité d'avoir la fibre, me limitant à 5Mbits descendants et 700Kbits montant est assez redhibitoire avec Free + FranceTélécom. Attendre des jours meilleurs ? Prendre des contrats, résilier si cela ne marche pas... je n'ai pas des mois à perdre.

A noter enfin que par sécurité j'ai deux cartes réseaux sur le serveur, une pour le réseau local et une adressée par le NAT (ce qui permet de mieux définir les règles de firewall).

A bientôt

Trebly

[chrtophe]

Pour vulgariser le NAT loopback, c'est un peu comme chercher à s'appeler soi-même au téléphone.

Ca n'a de sens que dans de rares cas particuliers. D’Où le fait que même si ça existe, ce n'est que rarement dispo.

Les BOX des FAIs sont faites pour éviter au maximum les probs de fausses manips des utilisateurs "hétéroclites", donc ça me parait logique qu'ils ne mettent pas la fonction à dispo. Allez demander à orange business service pour rigoler, j'ai déjà eu le cas, car ça emmerdait une hystérique de taper l'adr ip au lieu de l'url visible sur le web d'un serveur en interne, j'ai pas oser lui dire qu'on pouvait créer un marque page sous peine de m'en prendre une , le fichier host c'est bien mais quand il faut s'en taper une trentaine ça commence à être moins sympa.

D'ailleurs sur un standard téléphonique, que composez-vous normalement, le numéro de poste ou le numéro à 10 chiffres ,. J'ai eu le cas pas plus tard que hier, dans une entreprise un utilisateur cherchait à envoyer un fax à un collègue un étage plus haut, on me dit le FAX marche pas, à part ça je suis pas téléphoniste il s'avère qu'en composant le numéro du fax en haut, le standard me répond numéro inexistant ou injoignable, alors que de l’extérieur RAS. Caméra café, trop fainéant pour monter 1 étage, et en plus il y a un ascenseur: le choc de compétitivité ?

[sevyc64]

Les adresses URL gérées localement font l'objet de définition de DynHost et CNAME(s) sur le site hébergeur (j'ai un hébergement, mais il n'y a pas d'outils de débug. Donc OK, et encore des pb de niveau d'outils Php, Mysql. Donc la solution permettant un développement interactif est un serveur de développement à coté de soi. Donc mon serveur local est un appendice défini par un DynHost chez mon hébergeur).

Donc, des CNAME renvoient à une adresse (différente) vers ma Box via un DynHost qui pointe vers mon IP fixe (Free - ceci étant ça marche aussi en dynamique avec sur le serveur DirectUpdate V4).

Là, j'ai pas tout compris !

Quand tu contacte ton url, qu'elle est l'adresse IP donnée (et donc le serveur réellement contacté) par le DNS ?
C'est ton serveur hébergé qui est contacté et qui se charge lui-même (via une transcription d'url sur ton dyndns) de contacter ton serveur local pour relayer la requete ou est-ce que ton dyndns redéfini directement l'url de départ de sorte que ce soit ton serveur local qui soit contacté directement et jamais ton serveur hébergé ?

Dans le premier cas, ça doit marché puisque la requete sur le serveur local vient d'internet. Dans le second cas, c'est du hairpinning et la box ne doit pas laisser passé, en tout cas pour les freebox.
Les freebox bloquent le hairpinning (y compris la v6 à priori) et n'offrent aucune option dans leur configuration pour le débloquer.
Pour les livebox, je ne sais toujours pas, je ne connais pas.

[Trebly]

Bonsoir,

Je réponds mais en reformulant.

Mon hébergement est mutualisé chez OVH. Cela n'est pas important. Nous sommes dans la gestion DNS OVH.

Chez OVH j'ai un sous domaine yyy.xxx.net qui est défini en DynHost vers l'IP de la box (je signale que si l'IP n'était pas fixe (DirectUpdate V4 avec le mot de passe donné par OVH renseignerait l'IP affectée par le fournisseur d'accès).
Les enregistrement CNAME font pointer les sous domaines xnnn.xxx.net vers yyy.xxx.net

Conséquence quand une requête arrive vers x555.xxx.net elle est redirigée vers l'IP de ma Box.
Ma box a un NAT qui dirige le requêtes entrantes (qui ne sont pas des réponses) via une translation de port vers Apache qui écoute ce port.

x555.xxx.net est défini dans Apache (comme 40 autres) en virtualHost qui va exécuter la requête.

Ce qui est certain c'est que quand la requête part du réseau local de machine x elle est réentrante via la box vers la machine y. On est face à un mécanisme du type hairpinning. Ceci d'autant plus que Tracert montre que l'on en sort pas (la redirection vers le NAT se fait au niveau de la FreeBox). On peut penser cf. la suite qu'une translation d'adresses est effectuée après la première requête par la DNS de la Box, et c'est pour cette raison que le mécanisme a lieu.
Par conséquent je peux exécuter mes requêtes depuis mon poste de développement exactement comme si les sites étaient hébergés physiquement chez OVH (c'est la cas pour certain, puisque quand ils sont au point, je télécharge et supprime le CNAME qui pointe vers yyy.xxx.net (DynHost) - le sous domaine étant enregistré préalablement bien sur et pointe alors vers un répertoire local chez OVH). Le basculement est quasi instantané (qq minutes d'arrêt du site le temps de synchroniser les bases Mysql).

Il y a donc lieu de comprendre le mécanisme mis en jeu, puisque le hairpinning ne fonctionne théoriquement pas.
Là je ne sais plus exactement (parce que je n'ai pas les outils pour analyser les en têtes de blocs), donc je fais des hypothèses (basées sur mes recherches sur la gestion des DNS et sur Apache VirtualHost) :

Lorsque le serveur DynHost OVH construit l'en tête http il semble bien (je ne sais plus où je l'ai lu) que l'url principale soit IP+yyy.nnn.net complétée de l'url complète d'origine. C'est Apache qui fait le tri. (Désolé j'écris en réfléchissant), avec un rapport adéquat utilisateur je devrais pouvoir générer la trace.

J'ai donc un peu de travail... Il me semble bien, mais il y a plus de six mois, que un xnnn.xxx.net n'était pas bien défini et que comme j'ai une trappe pour le sous domaine principal yyy.xxx.net c'est lui qui a reçu le paquet et généré un erreur (avec un message adapté au cas).

Je n'ai pas d'explication complète mais c'est bien comme cela que ça fonctionne.
La même configuration, avec le même NAT ne passe pas avec une LiveBox et c'est d'ailleurs le VirtualHost yyy.xxx.net qui répond toujours.

Voilà pour le hairpinning ou pseudo-hairpinning, solution que je voudrais bien pouvoir reconduire.

Maineant je voudrais répondre à chrtophe :
J'ai développé (j'ai pas relu, pardon, il est tard) l'intérêt majeur de la fonction.

Grâce à ce fonctionnement, quel que soit le lieu du serveur les adresses, marque page etc. sont les mêmes.
En local je développe, le client ou le partenaire, en utilisant exactement les mêmes url (i.e. page html en dur pour naviguer et tester) de n'importe où accède au serveur local tout comme moi.
Si je déplace mon portable de développement (Asus G73SW avec 16Go et 4To de disques) chez le client, j'exécute ma démo comme à la maison (avec FireFox et les Macro ça roule tout seul).

J'ai essayé, puisque qu'avec la livebox rien ne marchais, d'utiliser Host (comme je faisias il y a 15ans), la galère, OK pour quelques url, mais avec des séquences de test et des query c'est fini (il faut écrire un morceau de soft en php mais quelle galère). comme j'ai trois postes de test... et fais faire des test depuis l'extérieur...
J'ai essayé de faire fonctionner une DNS locale pour faire le travail, j'ai abandonné.
Le tout se complétent des problèmes de sécurité... et du paramétrage de firewall, du serveur ftp, du smtp... seul je n'en peux mais.

Par contre je voudrais définir un solution fiable, parce que je dois re-déménager quelques mois à partir de Mai... et je voudrais pouvoir continuer à travailler.
J'envisage aussi de passer à la fibre, mais je ne suis pas sur du fonctionnement...

Je pense avoir répondu avec précision et que l'on pourra faire avancer la question.
Il serait bien que dans ce sujet on arrive à définir une solution qui marche toujours pour configurer un poste de développement presque dématérialisable.

C'est extrêmement efficace, de pouvoir débugger avec FireBug, de copier coller, corriger, adapter sur l'éditeur php, css, js ouvert avec Eclipse, faire sauve (sources en réseau local) puis mise-à-jour sur le navigateur et voir le résultat (ou le partenaire ou le client à l'autre bout du monde) en moins d'une minute souvent...

Cordialement

Trebly

A bientôt

[Trebly]

Bonjour,

En relisant ce sujet je vois combien ce qui j'ai écrit, même juste, clair pour celui qui était le nez dans le problème (moi-même son auteur), avec profusion de détails (pour être clair et précis), devient très vite illisible deux mois plus tard, même pour lui-même, sans un effort de concentration.
Alors que dire des lecteurs qui ne sont pas au cœur du sujet, pardon à eux. Pour moi c'était limpide.

En général depuis toujours je ne travaillais pas seul et avais la possibilité de faire relire mes textes (ce qui était réciproque), ce qui évitait ce genre de problème de communication sur les question complexes, mais ce n'est plus le cas.

Ces quelques lignes pour préciser et éclairer trois questions:

• Le hairpinning suppose une résolution inverse d'adresses par un "reverse proxy" ce que décrivent pas mal d'articles (Cisco en particulier et MS)
• Je viens de vérifier l'adresse inverse de mes sites joints en hairpinning via tracert :
  Tracert [url ext] :
  * [url ext] -> [ip de la box].proxad.net
  Et le serveur est joint directement via le NAT qui adresse les entrées sur port 80 sur un port spécifique et l'IP utile du serveur (qui va être écoutée par Apache)
• Je viens de vérifier que la série des matériels modem+routeur TP-Link (W8970 - W8980 et les nouveaux W9980) on pour les firmware récents (<1an : "Build 131012 puis 140408 de la plateforme matérielle V1") la fonction hairpinning en clair. Les articles cités plus haut dans la discussion dont http://opensimulator.org/wiki/NAT_Loopback_Routers donnent une list de matériels

A propos du dyndns et des CNAME que j'utilise définis dans la "zone DNS" OVH :

Code :

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

1
2
3
4
<url externe 1> CNAME <url site principal "pivot">
<url externe 2> CNAME <url site principal "pivot">
etc.
<url site principal "pivot"> DYNHOST <IP de la box : fixe chez Free>

dans cette configuration en soumettant

Code :

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

c:\tracert <url externe 1>

J'ai le retour (test exécuté après une utilisation antérieure - je ne peux pas contrôler pour le premier appel):

Code :

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

* pas 1 : [<url externe 1> -> <IP de la box : fixe chez Free> -> proxad.net]

Le NAT définit un translation de port vers l'adresse interne du serveur
port 80 -> port xxxx sur IP interne de la carte du serveur

Ainsi les entrants sur port 80 seront dirigés avec l'adresse IP et sur le port concerné.
Le firewall local (utilisation d'une station en mode server donc doté d'un firewall local) sera paramétré en conséquence pour accepter tout les entrant sur le port xxxx
cette adresse atteint directement le serveur à l'adresse IP : <IP de la box>xxx

Apache, pour sa part contient en .conf les instructions suivantes

Code :

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

listen  IP de la box>:xxxx

et

Code :

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

1
2
3
4
5
6
<VIRTUALHOST   IP de la box>:xxxx >
SERVERNAME  url_externe_1 
DocumentRoot ....
...
DirectoryIndex ...
</VIRTUALHOST>

J'ai plusieurs dizaines de sites accessibles de cette manière.

J'espère avoir apporté les éclaircissement utiles.

Cordialement

Trebly

Note : doit être adapté dans le cas d'utilisation de SSL et d'autres protocoles pour d'autres fonctions (dans mon cas un serveur ftp)