Faire une boucle vers l'adresse IP publique transférée depuis le réseau local - NAT en boucle

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

J'ai contacté mon FAI et leur ai demandé d'essayer de résoudre mes problèmes. Ce qu'ils m'ont proposé, c'est une autre adresse IP publique juste pour le serveur, Maintenant j'ai du trafic local sur le côté WAN de FreeBSD et nous avons créé des tuyaux spécifiques pour une meilleure efficacité de débit pour le trafic local vers l'adresse IP publique du serveur

Si c'est un routeur D-Link original (c'est-à-dire pas Rev. D / Version du firmware 1.00VG de Virgin Media), vous devriez pouvoir ajuster les paramètres pour contourner cela. (Cependant, je suis d'accord avec la suggestion du précédent intervenant d'utiliser DD-WRT 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. Cliquez sur le bouton radio Indépendant du point de terminaison sous Filtrage du point de terminaison TCP, comme indiqué dans la capture d'écran ci-dessous (ou consultez l'émulateur de routeur sur le site web de D-Link)
5. Enregistrez les modifications; vous avez terminé

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

D'un point de vue technique, la meilleure solution à ce problème est d'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 dispose de suffisamment d'adresses pour éviter le NAT, vous n'aurez donc pas besoin de NAT en boucle pour IPv6. Et une fois que vous avez activé IPv6 et créé des enregistrements AAAA, tout client prenant en charge RFC 8305 tentera d'utiliser IPv6 avant IPv4. Cela signifie que vous n'aurez pas besoin de NAT en boucle pour IPv4 non plus, 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 du monde ait activé IPv6 également.

C'est aussi plus rapide.

L'utilisation d'IPv6 vous offrira de meilleures performances que le NAT en boucle.

Avec le NAT en boucle, votre client enverra un paquet via un commutateur vers le routeur, le routeur effectuera alors deux cycles de traduction et enverra enfin le paquet via le commutateur vers le serveur. Les paquets du serveur vers le client suivront le même chemin en sens inverse.

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

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

Et si le FAI n'a pas IPv6 ?

Si vous utilisez un FAI qui ne prend pas en charge IPv6, je remettrais en question le fait d'héberger des serveurs sur ce réseau. Voici mes suggestions sur ce qu'il faut faire si le FAI ne prend pas actuellement en charge IPv6.

Dites d'abord au FAI que vous avez besoin d'IPv6. Et peut-être leur rappeler que le protocole IPv6 existe depuis 20 ans, donc ils sont très en retard dans leur support. Si cela ne suffit pas pour que le FAI vous prenne au sérieux, commencez à chercher d'autres FAI.

Si vous trouvez un FAI prenant en charge IPv6, vous pouvez travailler avec les deux FAI pendant une période de transition. Sur le routeur connecté au nouveau FAI, vous pouvez désactiver l'IPv4 côté LAN, puis connecter les côtés LAN des deux routeurs au même commutateur. IPv4 et IPv6 sont deux protocoles indépendants et donc il n'y a aucun problème si ces connexions passent par des routeurs différents. En bonus, cela vous donne un certain niveau de redondance en cas de panne d'une des connexions.

Si vous ne trouvez pas de FAI prenant en charge IPv6, vous devriez envisager de déplacer votre serveur vers un centre d'hébergement. Avec un serveur dans un centre d'hébergement, vous dépendez moins de la localisation géographique et pour cette raison, il y a plus de concurrence entre les fournisseurs, ce qui aidera à garantir qu'il en existe un qui satisfait vos besoins.

Déplacer le serveur vers un centre d'hébergement ne donnera pas à vos clients l'IPv6, mais déplacer le serveur signifie que vous n'aurez plus besoin de NAT en boucle pour y accéder.

Ce que vous ne devriez pas faire

Ne pas activer IPv6 et créer des enregistrements AAAA si vous n'avez pas de moyen de router le trafic IPv6. Si votre FAI ne supporte pas IPv6 mais que vous choisissez d'activer quand même IPv6 sur votre LAN (peut-être en utilisant des adresses RFC 4193) et de créer des enregistrements AAAA, cela fonctionnera pour les clients sur votre LAN accédant au serveur sur votre LAN. Mais la communication entre votre LAN et le monde extérieur tenterait d'abord IPv6 (ce qui ne fonctionnerait pas), et vous devriez vous en remettre à passer à l'IPv4 qui, au mieux, ralentira un peu ou au pire, ne se produira pas.

Depuis que j'ai également posé cette question (voir Comment accéder à un service réseau NATé derrière un pare-feu depuis l'intérieur en utilisant son IP externe?) et ai été redirigé ici mais les réponses ici n'ont pas fourni de solution (contrairement aux explications générales), laissez-moi fournir ma solution Linux spécifique à iptables ici pour éviter à tout le monde quelques heures d'expérimentation. Ce fichier est au format iptables-restore et peut être lu directement dans iptables (après avoir édité les adresses IP bien sûr). Ceci est pour un serveur web (port 80) et uniquement pour IPv4 - les règles pour IPv6 et pour SSL (port 443) sont analogues.

# Redirection de port pour l'accès à VM / Conteneur avec NAT "hairpin".
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# C'était une simple redirection de port - l'accès fonctionne depuis l'extérieur mais pas depuis l'intérieur
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# C'est le vrai NAT hairpin qui permet à "web.local" de s'accéder via l'IP externe de l'hôte VM.
# D'abord, nous devons masquer le trafic sortant par l'interface externe:
-A POSTROUTING -o eth0 -j MASQUERADE

# Ensuite, nous devons rerouter le trafic entrant sur l'IP publique vers l'IP locale:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# Enfin, nous devons indiquer au routeur que l'IP source de tout trafic
# provenant du LAN doit être réécrite en source lorsqu'elle va vers le serveur web:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Remplacez lan.local, web.local et web.public.com par votre réseau local (par exemple, 10.0.x.0/24), l'IP locale de votre serveur web (par exemple, 10.0.1.2), et l'IP publique de votre routeur (par exemple, 4.5.6.7). Le -4 sert juste à permettre les règles IPv6 et IPv4 dans le même fichier (de telles lignes sont ignorées par ip6tables). N'oubliez pas 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 fait arracher les cheveux en essayant réellement de mettre en œuvre les explications dans cette question. J'espère n'avoir rien oublié.

Comme il s'agit d'une question canonique. Je répondrai si vous avez un routeur Sonicwall.

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

Ce document décrit comment un hôte sur un LAN SonicWall peut accéder à un serveur sur le LAN SonicWall en utilisant l'adresse IP publique du serveur en FQDN. 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 principal est 3.3.2.1. Disons que vous avez un site Web pour vos clients, et son nom d'hôte est . Vous avez déjà écrit les politiques et règles nécessaires pour que les personnes extérieures puissent accéder au site Web, mais il fonctionne réellement sur un serveur côté privé 10.100.0.2. Maintenant, imaginez que vous êtes une personne utilisant un ordinateur portable côté privé, avec une IP de 10.100.0.200. Vous voulez accéder au serveur en utilisant son nom public, car vous faites la même chose lorsque votre ordinateur portable est avec vous en déplacement. Si vous êtes côté privé, et que vous demandez http://www.example.com, le bouclage est ce qui rend cela possible, même si le serveur est en réalité juste à côté de vous sur une adresse IP locale.

Pour permettre cette fonctionnalité, vous devez créer une politique de bouclage NAT, également connue sous le nom de réflexion NAT ou de hairpin.

Politique de bouclage utilisant l'adresse IP de l'interface WAN

Connectez-vous à l'interface graphique de gestion SonicWall.
Accédez à Gérer | Règles | Sous-menu des politiques NAT.
Cliquez sur le bouton Ajouter.
Créez la politique NAT suivante.
Source d'origine : Sous-réseaux LAN (ou sous-réseaux protégés par le pare-feu si vous voulez inclure des hôtes dans d'autres zones)
Source traduite : IP de l'interface WAN
Destination d'origine : IP de l'interface WAN
Destination traduite : (objet serveur LAN)
Service d'origine : Tout
Service traduit : Original
Interface entrante : Tout
Interface sortante : Tout

Le SonicWall reconnaîtra le service externe auquel vous essayez de contacter, et réécrira l'adresse de destination pour correspondre à l'adresse interne du serveur, ce qui le rendra transparent pour l'ordinateur.