Impossible de joindre une machine interne avec son adresse publique
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 ?
Server sur réseau local : accès en "hairpinning", "NAT LoopBack"
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"
Citation:
Envoyé par
sevyc64
Ç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 :
Citation:
Envoyé par
sevyc64
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...
Citation:
Envoyé par
sevyc64
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
Serveur sur réseau local : accès en "hairpinning", "NAT LoopBack"
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:
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
Hairpinning (NAT Loopback) Norme IETF RFC4787
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
Importance de la résolution proxy inverse pour le hairpinning et clarifications de précédents messages
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:
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:
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:
* 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>:xxxx
Apache, pour sa part contient en .conf les instructions suivantes
Code:
listen IP de la box>:xxxx
et
Code:
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)
