Question Boucle vers l'adresse IP publique transférée à partir du réseau local - Hairpin NAT


C'est un Question canonique sur le NAT en épingle à cheveux (NAT en boucle).

La forme générique de cette question est:

Nous avons un réseau avec des clients, un serveur et un routeur NAT. Le routeur est redirigé vers le serveur par le port, de sorte que certains de ses services sont disponibles en externe. Nous avons DNS pointant vers l'IP externe. Les clients du réseau local ne parviennent pas à se connecter, mais le travail externe.

  • Pourquoi cela échoue?
  • Comment créer un schéma de dénomination unifié (noms DNS qui fonctionnent localement et en externe)?

Cette question a repondu a partir de multiples autres questions. À l'origine, ils faisaient référence à FreeBSD, D-Link, Microtik et à d'autres équipements. Ils essaient tous de résoudre le même problème cependant.


42
2017-08-18 15:16


origine


Si votre objectif est de tester l'accès à partir d'Internet, il est inutile de modifier les itinéraires du routeur et / ou les paramètres DNS, car au mieux, de l'intérieur, vous vérifieriez que la partie interne du routeur fonctionne. Je vous suggère d'utiliser un serveur proxy quelque part à l'extérieur.


Réponses:


Ce que vous recherchez s'appelle "le NAT en épingle à cheveux". Les demandes émanant de l'interface interne pour une adresse IP attribuée à l'interface externe doivent être NAT, comme si elles venaient de l'interface externe.

Je ne connais pas du tout FreeBSD, mais je lis le manuel "pf" pour OpenBSD (http://www.openbsd.org/faq/pf/rdr.html) les solutions proposées de DNS fractionné, utilisant un réseau DMZ ou de proxy TCP me font penser que "pf" ne prend pas en charge le NAT en épingle à cheveux.

Je regarderais la voie du DNS à horizon divisé et n'utilisera pas les adresses IP dans les URL en interne, mais plutôt les noms.


14
2017-08-18 15:30



J'ai rencontré ce fil en essayant de résoudre le même problème, et s'il est vrai que FreeBSD ne prend pas en charge le nat en épingle à cheveux, il existe des moyens de rediriger et de NAT le trafic interne -> externe -> interne. - eggo
Par exemple: no nat on $int_if proto tcp from $int_if to $int_net  , nat on $int_if proto tcp from $int_net to $hairpin_int port $hairpin_ports -> $int_if , rdr on $int_if proto tcp from $int_net to $ext_if port $hairpin_ports -> $hairpin_int - eggo


Depuis cela a été élevé pour être le question canonique sur le NAT en épingle à cheveuxJe pensais qu'il devrait probablement y avoir une réponse plus valide que celle qui est actuellement acceptée, qui (bien qu'excellente) concerne spécifiquement FreeBSD.

Cette question concerne les services fournis par les serveurs sur les réseaux IPv4 adressés par RFC1918, qui sont mis à la disposition des utilisateurs externes en introduisant un NAT de destination (DNAT) au niveau de la passerelle. Les utilisateurs internes essaient ensuite d'accéder à ces services via l'adresse externe. Leur paquet sort du client vers le dispositif de passerelle, qui réécrit l'adresse de destination et l'injecte immédiatement dans le réseau interne. C’est ce virage rapide que fait le paquet à la passerelle qui donne lieu au nom épingle à cheveux NAT, par analogie avec le virage en épingle à cheveux.

Le problème se pose lorsque le périphérique de passerelle réécrit l'adresse de destination, mais pas l'adresse source. Le serveur reçoit alors un paquet avec une adresse de destination interne (la sienne) et une adresse source interne (celle du client); il sait qu'il peut répondre directement à une telle adresse, alors il le fait. Comme cette réponse est directe, elle ne passe pas par la passerelle, qui n'a donc jamais la possibilité d'équilibrer l'effet du NAT de destination entrant sur le paquet initial en réécrivant l'adresse source du paquet de retour.

Le client envoie donc un paquet à un externe Adresse IP, mais obtient une réponse d'un interne Adresse IP. Il n'a aucune idée que les deux paquets font partie de la même conversation, donc aucune conversation ne se produit.

La solution est que pour les paquets qui ont besoin d'un tel NAT de destination et qui atteignent la passerelle à partir du réseau interne, pour effectuer également le NAT source (SNAT) sur le paquet entrant, généralement en réécrivant l’adresse source pour qu’elle soit celle de la passerelle. Le serveur pense alors que le client est la passerelle elle-même et y répond directement. Cela donne à la passerelle une chance d'équilibrer les effets de DNAT et de SNAT sur le paquet entrant en réécrivant les adresses source et de destination sur le paquet de retour.

Le client pense qu'il parle à un serveur externe. Le serveur pense communiquer avec le périphérique de passerelle. Toutes les parties sont heureuses. Un diagramme peut être utile à ce stade:

enter image description here

Certains périphériques de passerelle grand public sont suffisamment intelligents pour reconnaître les paquets pour lesquels une deuxième étape NAT est nécessaire. Ceux-ci fonctionneront probablement immédiatement avec un scénario NAT en épingle à cheveux. D'autres ne le sont pas et ne le feront pas non plus, et il est peu probable qu'on puisse les faire fonctionner. Une discussion sur les périphériques grand public qui sont hors sujet pour Server Fault.

On peut généralement dire aux périphériques réseau appropriés de fonctionner, mais - comme ils ne sont pas en train de deviner leurs administrateurs - il faut leur dire de le faire. Utilisations de Linux iptables faire le DNAT ainsi:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

qui activera le DNAT simple pour le port HTTP, vers un serveur interne sur 192.168.3.11. Mais pour activer le NAT en épingle à cheveux, il faudrait également une règle telle que:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

Notez que ces règles doivent se trouver au bon endroit dans les chaînes pertinentes pour fonctionner correctement, et en fonction des paramètres définis dans filter chaîne, des règles supplémentaires peuvent être nécessaires pour permettre au trafic NATted de circuler. Toutes ces discussions sortent du cadre de cette réponse.

Mais comme d’autres l’ont dit, activer correctement le NAT en épingle à cheveux n’est pas le meilleur moyen de traiter le problème. Le meilleur est DNS à horizon divisé, où votre organisation fournit des réponses différentes à la recherche d'origine en fonction de l'emplacement du client demandeur, soit en ayant différents serveurs physiques pour les utilisateurs internes par rapport aux utilisateurs externes, soit en configurant le serveur DNS pour qu'il réponde différemment en fonction de l'adresse du client demandeur.


46
2017-11-27 12:20



Je m'interroge un peu sur les adresses des paquets échangés entre passerelle et serveur. Ne serait-il pas plus cohérent si le serveur voyait l'adresse IP publique du routeur comme l'adresse IP du client? Techniquement, les deux peuvent fonctionner, mais pour rester cohérent avec la façon dont les autres serveurs voient les clients, il devrait utiliser l'adresse IP publique. - kasperd
J'affirme que vous faites référence au dernier cas, "le NAT en épingle à cheveux approprié". L'essentiel est de réécrire l'adresse source sur le paquet entrant de manière à ce qu'il soit renvoyé au routeur, ce qui peut alors inverser le DNAT et le SNAT et ainsi éviter le problème. Laquelle des nombreuses adresses que le routeur utilise pour ce faire est plutôt un point de goût, et si vous le faites avec iptables, est certainement quelque chose que vous pouvez configurer si vous le souhaitez. - MadHatter
De nombreux administrateurs, dont moi-même, considèrent le DNS à horizon divisé comme un remède pire que la maladie. Si un SNAT supplémentaire peut être qualifié de maladie. Un DNS à vues divisées déroute les humains tout en simplifiant la vie des routeurs. Ce sujet serait mieux traité par une question / réponse ServerFault séparée. - kubanczyk
Ma réponse concerne beaucoup le NAT en épingle à cheveux. Je peux voir les avantages et les inconvénients de l’ouverture d’une question canonique de type "DNS à horizon divisé": les avantages comprennent le fait d’avoir une question consacrée aux utilisations et aux problèmes de SHDNS, mais les inconvénients sont que cette question a déjà été posée avec beaucoup d’autres questions ayant trait à cela a fusionné avec cela, alors cela pourrait arriver à votre question aussi. Si c'était moi, je parlerais de la méta et je chercherais un consensus. Si une telle question est effectivement écrite, j’ai hâte de lire votre réponse! - MadHatter
@MadHatter Où devrais-je écrire la commande iptables? sur le client ou la passerelle ou le serveur? - Rock Balbao


Le problème ici est que votre routeur ne fait pas de NAT l'adresse de votre client interne. Ainsi, la négociation TCP échoue.

Supposons les adresses IP suivantes

  • Client: 192.168.1.3
  • Serveur: 192.168.1.2
  • Routeur interne: 192.168.1
  • Routeur externe: 123.123.123.1

Voici ce qui se passe:

  1. Le client (192.168.1.3) envoie TCP-SYN à votre adresse IP externe, port 80 (123.123.123.1:80)
  2. Le routeur voit la règle de transfert de port et transfère le paquet au serveur (192.168.1.2:80) sans modifier l'adresse IP source (192.168.1.3)
  3. Le client attend un SYN-ACK de l'IP externe
  4. Le serveur envoie sa réponse directement au client, car il se trouve sur le même sous-réseau. Il n'envoie pas le paquet au routeur, ce qui inverserait le NAT.
  5. Le client reçoit un SYN-ACK de 192.168.1.2 au lieu de 123.123.123.1. Et le jette.
  6. Le client attend toujours un SYN-ACK à partir de 123.123.123.1 et expire.

8
2017-10-10 11:32





Pourquoi ne pas utiliser des DNS fractionnés au lieu de coder en dur des adresses IP partout? Votre domaine externe devrait pointer 217.x.x.x à l'extérieur, puis 192.x.x.x à l'intérieur.


4
2017-08-20 08:42



Si vous avez un moment, pourriez-vous préciser ce qu'est le DNS Split-Horizon, son fonctionnement et ses principaux inconvénients? C'est une question canonique maintenant et il serait bien d'avoir une réponse plus complète. - Chris S


Récemment répondu à une question similaire: Le NAT statique de Cisco ne fonctionne pas du côté du réseau local et vient de réaliser qu'il s'agit d'une question canonique. Alors permettez-moi de résumer la solution ici.

Tout d'abord: oubliez le NAT (si vous le pouvez) - la question n'est pas du tout de configurer le NAT. Il s'agit d'accéder à un serveur placé derrière un NAT, à la fois sur Internet et sur le réseau local. Utiliser deux zones DNS est une alternative viable, mais pas toujours la solution. Mais la solution existe et est incroyablement simple (bien que pas parfaite, probablement):

(1) sur le serveur: ajoutez l'adresse IP publique en tant qu'adresse IP secondaire sur l'interface réseau du serveur avec le masque 255.255.255.255 (le service Web ou ce que vous souhaitez sur le serveur doit également écouter cette adresse IP); tous les systèmes d'exploitation modernes vous le permettent (ou une interface de bouclage avec l'adresse IP publique qui lui est attribuée peut être utilisée au lieu d'ajouter une adresse IP secondaire à l'interface principale).

(2) sur les hôtes du réseau local: ajoutez un itinéraire d'hôte pour l'adresse IP publique. Par exemple, pour les hôtes Windows, utilisez la commande suivante: route -p add 203.0.113.130 masque 255.255.255.255 192.168.1.11 (vous pouvez également utiliser l'option "route statique" de DHCP pour distribuer la route). Ou, s’il existe un (des) commutateur (s) / routeur (s) L3 entre les clients et le routeur connecté à Internet, configurez cette route hôte sur ce (ces) commutateur (s) / routeur (s) intermédiaire (s), sur les clients.

Pour ceux qui sont concernés par la négociation à trois voies TCP: cela fonctionnera correctement dans la configuration proposée.

Merci de donner votre avis (au moins, votez)


2
2017-11-03 11:14



L'exigence n ° 2 fait que cela ne fonctionne pas bien sur les réseaux BYOD ... - Michael


Ill répondre à mes questions juste pour élargir les horizons pour ceux qui ont des problèmes similaires.

Je suis contacté par mon fournisseur d'accès et leur ai demandé d'essayer de résoudre mes problèmes. Ce qu'ils m'avaient offert, c'est une autre adresse IP publique juste pour le serveur, Maintenant, j'ai du trafic local du côté WAN de FreeBSD et nous avons créé des pipes spécifiques pour débit plus rapide du trafic local vers l'IP publique du serveur


1
2017-08-20 08:37



Cette solution implémente un Réseau de périmètre ou DMZ et constitue une bonne alternative au Hairpin NAT et au Split-Horizon DNS. - Chris S


S'il s'agit d'un routeur D-Link d'origine (c'est-à-dire et non de la version 1.00VG du micrologiciel de Virgin Media), vous devriez pouvoir ajuster les paramètres pour résoudre ce problème. (Cependant, je suis d'accord avec la suggestion du DD-WRT de l'affiche précédente pour de nombreuses autres raisons!)

  1. Connectez-vous à l'interface Web du routeur
  2. Cliquez sur l'onglet Avancé en haut
  3. Cliquez sur l'onglet Paramètres du pare-feu à gauche.
  4. Clique le Indépendant du point de terminaison bouton radio sous Filtrage des points de terminaison TCP, comme indiqué dans la capture d'écran ci-dessous (ou voir le émulateur de routeur sur le site de D-Link)
  5. Sauvegarder les modifications; vous avez terminé

D-Link router web UI screenshot

Cette capture d'écran provient du modèle Rev. C; le vôtre peut être légèrement différent.


1
2018-03-11 02:37