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

C’est une 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. Il existe une redirection de port sur le routeur vers le serveur, 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 fonctionnant 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.

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 pour le DNS fractionné, en utilisant un Le réseau DMZ ou le proxy TCP me laisse croire que "pf" ne prend pas en charge le NAT en épingle à cheveux.

Je regarderais la voie du DNS à demi-horizon et n'utilisant pas les adresses IP dans les URL en interne mais utilisant plutôt les noms.

Étant donné que cette question a été érigée en canonique sur le NAT en épingle à cheveux , j’ai pensé qu’elle devrait probablement avoir une réponse plus générale que celle 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 périphérique 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 le paquet effectue à la passerelle qui donne son nom au NAT en épingle à cheveux , par analogie avec le tour 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 ensuite 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 à une adresse IP externe , mais reçoit une réponse d'une adresse IP interne . 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 de ce NAT de destination et qui atteignent la passerelle à partir du réseau interne , ils doivent également effectuer un 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 qu'il parle au périphérique de passerelle. Toutes les parties sont heureuses. Un diagramme peut être utile à ce stade:

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 dans 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. Linux utilise iptablespour faire le DNAT ainsi:

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

qui permettra DNAT simple pour le port HTTP, à 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. Selon les paramètres de la filterchaî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 la meilleure façon de traiter le problème. Le meilleur est le DNS fractionné , dans lequel votre organisation fournit des réponses différentes pour la recherche initiale, en fonction de l'emplacement du client demandeur, en disposant de serveurs physiques différents pour les utilisateurs internes et externes, ou en configurant le serveur DNS de manière à répondre différemment en fonction des besoins. l'adresse du client demandeur.

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 renvoie 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.

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

S'il s'agit d'un routeur D-Link d'origine (c.-à-d. Non Rev. D / Firmware version 1.00VG 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 beaucoup d'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. Cliquez sur le bouton radio Endpoint Independent sous Filtrage TCP des points finaux , comme indiqué dans la capture d'écran ci-dessous (ou consultez l' émulateur de routeur sur le site Web de D-Link).
5. Sauvegarder les modifications; vous avez terminé

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

Nous avons récemment répondu à une question similaire: le NAT statique de Cisco ne fonctionnait pas du côté du réseau local et venait de réaliser qu'il s'agissait 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 à partir d’Internet et du 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 vous pouvez utiliser une interface de bouclage avec l'adresse IP publique qui lui est attribuée au lieu d'ajouter une adresse IP secondaire à l'interface principale).

(2) sur les hôtes LAN: 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 mask 255.255.255.255 192.168.1.11 (vous pouvez également utiliser DHCP " "route statique" 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.

S'il vous plaît fournir des commentaires (au moins, voter).

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 proposé, c’était une autre adresse IP publique réservée au serveur. Maintenant, j’ai un trafic local du côté WAN de FreeBSD et nous avons créé des tubes spécifiques pour un débit plus rapide du trafic local vers l’IP publique du serveur.

D'un point de vue technique, la meilleure solution à ce problème consiste à activer IPv6 sur votre réseau. Lorsque IPv6 est activé, vous devez créer un enregistrement AAAA pour votre domaine. Conservez l’enregistrement A existant pointant vers l’IPv4 externe du routeur . Créez un enregistrement AAAA pointant vers l'adresse IPv6 du serveur .

IPv6 a suffisamment d'adresses pour éviter le NAT, vous n'aurez donc pas besoin d'un NAT en épingle à cheveux pour IPv6. Et une fois que vous avez activé IPv6 et créé des enregistrements AAAA, tout client prenant en charge le RFC 8305 essayera IPv6 avant IPv4. Cela signifie que vous n'avez pas besoin du NAT en épingle à cheveux pour IPv4, car les clients ne l'utiliseront pas.

Vous aurez toujours besoin de votre NAT IPv4 existant pour les connexions sortantes et du transfert de port pour les connexions entrantes jusqu'à ce que la plupart des pays aient également activé IPv6.

C'est plus rapide aussi.

L'utilisation d'IPv6 vous donnera de meilleures performances que le NAT en épingle à cheveux.

Avec le NAT en épingle à cheveux, votre client envoie un paquet au routeur via un commutateur. Le routeur effectue ensuite deux tours de traduction et envoie ensuite le paquet au serveur via le commutateur. Les paquets du serveur au client passeront par tout ce chemin en sens inverse.

Avec IPv6, vous évitez le NAT. Au lieu de cela, les paquets sont envoyés directement via le commutateur entre le client et le serveur. Cela signifie que, lors d'un aller-retour, vous réduisez le nombre de passages par le commutateur de 4 à 2 et vous évitez 2 passages par le routeur et les 4 traductions que le routeur aurait effectuées. Cela se traduit par de meilleures performances.

Cela est vrai même si vous utilisez un commutateur intégré dans la même boîte que le routeur.

Que se passe-t-il si le FAI n'a pas IPv6?

Si vous utilisez un fournisseur d'accès à Internet qui ne prend pas en charge IPv6, je vais vous demander si vous devriez héberger des serveurs sur ce réseau. Voici mes suggestions sur ce qu'il faut faire si le fournisseur de services Internet ne prend actuellement pas en charge IPv6.

Commencez par dire au fournisseur de services Internet que vous avez besoin d’ IPv6. Et rappelez-leur peut-être que le protocole IPv6 existe depuis 20 ans et qu’ils ont trop tardé à le prendre en charge. Si cela ne suffit pas pour que le FAI vous prenne au sérieux, commencez à chercher d’autres FAI.

Si vous trouvez un fournisseur de services Internet prenant en charge IPv6, vous pouvez utiliser les deux fournisseurs de services Internet pendant une période de transition. Sur le routeur connecté au nouveau fournisseur de services Internet, vous pouvez désactiver IPv4 du côté du réseau local, puis connecter les côtés du réseau local des deux routeurs au même commutateur. IPv4 et IPv6 sont deux protocoles indépendants et, en tant que tels, le fait que ces connexions passent par des routeurs différents ne pose aucun problème. En tant que bénéfice supplémentaire, vous bénéficiez d'une certaine redondance si l'une des connexions est en panne.

Si vous ne trouvez pas de fournisseur de services Internet prenant en charge IPv6, vous devriez envisager de transférer votre serveur vers un centre d'hébergement. Avec un serveur hébergé chez un hébergeur, vous êtes moins dépendant de votre localisation géographique. C'est pourquoi la concurrence entre les fournisseurs est plus grande, ce qui vous aidera à vous assurer qu'il en existe un qui réponde à vos besoins.

Le déplacement du serveur vers un hébergement ne donnera pas à vos clients IPv6, mais le déplacement du serveur signifie que vous n’avez plus besoin de NAT en épingle à cheveux pour l’atteindre.

Ce que vous ne devriez pas faire

N'activez pas IPv6 et ne créez pas d'enregistrements AAAA si vous ne pouvez pas acheminer le trafic IPv6. Si votre FAI ne prend pas en charge IPv6 mais que vous choisissez quand même d'activer IPv6 sur votre réseau local (peut-être en utilisant des adresses RFC 4193) et créez des enregistrements AAAA, cela fonctionnera pour les clients de votre réseau local qui atteignent le serveur de votre réseau local. Mais la communication entre votre réseau local et le monde extérieur essaierait d’abord d’essayer IPv6 (ce qui ne fonctionnerait pas), et vous vous en remettriez à IPv4, ce qui, au mieux, est un peu plus lent ou, au pire, ne se produit pas.

Depuis que j'ai également posé cette question (voir Comment puis-je accéder à un service réseau NATed derrière un pare-feu utilisant son adresse IP extérieure? ), J'ai été redirigé ici, mais les réponses fournies ici ne fournissaient pas de solution (contrairement aux explications génériques ). fournir ma iptablessolution Linux ( spécifique) ici pour éviter à tout le monde quelques heures d’expérimentation. Ce fichier est au iptables-restoreformat et peut être lu directement dans iptables (après avoir édité les adresses IP bien sûr). Ceci concerne un serveur Web (port 80) et uniquement pour IPv4 - les règles pour IPv6 et pour SSL (port 443) sont analogues.

# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Remplacer lan.local, web.localet web.public.comavec votre réseau local (par exemple. 10.0.x.0 / 24), IP locale de votre serveur web (par exemple 10.0.1.2), et IP publique de votre routeur (par exemple. 4.5.6.7). Cela -4consiste simplement à autoriser les règles IPv6 et IPv4 dans le même fichier (ces lignes sont ignorées par ip6tables). N'oubliez pas non plus de mettre les adresses IPv6 entre [crochets] lorsqu'elles incluent des déclarations de port, par exemple [fe0a:bd52::2]:80.

Ce sont toutes les choses qui m'ont poussé à me tirer les cheveux en essayant de mettre en pratique les explications de cette question. J'espère ne rien avoir oublié.

Je vais ajouter une réponse ici car les commentaires ici ne traitent pas de mon problème particulier. J'imagine que c'est parce que je suis tombé sur un mauvais bug du noyau Linux. La configuration est:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

Malgré cette image complexe, le seul changement pertinent par rapport aux situations évoquées dans d’autres commentaires est l’ajout du pont logiciel, br0. C'est là parce que la boîte de passerelle est également un point d'accès sans fil pour le réseau local.

Notre boîte de passerelle effectue toujours des tâches de NAT pour les machines du réseau local. Comme il ne possède qu'un seul port Ethernet, il est obligé de faire du NAT en épingle à cheveux. Je suppose que cela devrait simplement fonctionner avec les règles iptables données dans d’autres commentaires ici, mais du moins sur le noyau Linux 4.9. En vertu de la version 4.9, notre passerelle peut accéder à Internet, mais les machines du réseau local qui tentent d'y accéder via NAT ne le peuvent pas.

tcpdumpaffiche les réponses aux paquets entrants frappant eth0, mais ne le fait pas avec br0. L'exécution de cette commande corrige les problèmes suivants:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Avant que cette commande ne soit exécutée, les paquets entrants sont traités conformément au comportement par défaut du noyau, qui consiste à les transmettre au pont puis à leur transmettre les modules de routage du noyau. La commande force les paquets qui ne proviennent pas du réseau local à contourner le pont et à passer directement au routage, ce qui signifie que le pont n'a pas l'occasion de les laisser tomber. Les adresses de diffusion et de multidiffusion doivent être pontées, sinon des choses comme DHCP et mDNS ne fonctionneront pas. Si vous utilisez IPv6, vous devez également ajouter des règles.

Vous pourriez être tenté de résoudre le problème en utilisant ceci:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

J'étais certainement tellement tenté - c'était ma première tentative. Dès que je l'ai fait, les machines sur le réseau local ont eu accès à Internet, donc cela fonctionne pendant un moment. Ensuite, les événements suivants se sont produits (et je n'ai pas voulu répéter l'expérience):

1. Les temps de réponse sur le réseau LAN de la passerelle ont doublé toutes les 10 secondes environ, passant de 0,1 ms à 0,2 ms, 0,4 ms, 0,8 ms, 2 ms, etc., jusqu'à ce que le boîtier de la passerelle soit inaccessible depuis le réseau local. Cela sentait comme une tempête de paquets, mais STP était allumé partout.
2. Peu de temps après la mort de tous les points d'accès sans fil.
3. En essayant de diagnostiquer ce qui se passait avec le sans fil, tous les téléphones IP ont redémarré.
4. Peu de temps après, les machines câblées ont perdu tout contact avec le réseau local.

La seule solution était de redémarrer toutes les machines du bâtiment. La seule exception concernait les commutateurs matériels, qui ne pouvaient pas être redémarrés. Ils devaient être mis sous tension.

Comme c'est une question canonique. Je répondrai si vous avez un routeur Sonicwall.

L'expression à connaître est la politique de bouclage NAT

Ce document décrit comment un hôte d’un réseau local SonicWall peut accéder à un serveur situé sur le réseau local SonicWall à l’aide de l’adresse IP publique du serveur vers le nom de domaine complet. Imaginez un réseau NSA 4500 (SonicOS Enhanced) dans lequel le sous-réseau LAN principal est 10.100.0.0 / 24 et l’IP WAN primaire est 3.3.2.1. Disons que vous avez un site Web pour vos clients et que son nom d’hôte est. Vous avez déjà rédigé les règles et les règles nécessaires pour que les tiers puissent accéder au site Web, mais celui-ci fonctionne réellement sur un serveur côté privé 10.100.0.2. Imaginez maintenant que vous utilisez un ordinateur portable côté privé, avec un IP de 10.100.0.200. Vous souhaitez atteindre le serveur en utilisant son nom public, car vous faites la même chose lorsque votre ordinateur portable est avec vous sur la route. Si vous êtes assis du côté privé et demandez http://www.example.com>, le bouclage est ce qui permet que cela fonctionne, même si le serveur est juste à côté de vous sur une adresse IP locale.

Pour permettre cette fonctionnalité, vous devez créer une stratégie de bouclage NAT, également appelée réflexion NAT ou épingle à cheveux.

Stratégie de bouclage utilisant l'adresse IP de l'interface WAN

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Sonicwall reconnaîtra le service externe que vous essayez de contacter et réécrira l’adresse de destination pour l’adapter à l’adresse interne du serveur afin qu’elle soit transparente pour l’ordinateur.

Dans FreeBSD avec PF, c’est simple (dans votre fichier pf.conf):

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

192.168.20.8 serait le serveur Web interne.