Étant donné que cette question a été élevée au statut de question canonique sur le NAT en épingle à cheveux, j'ai pensé qu'elle devrait probablement avoir une réponse plus généralement valable que celle actuellement acceptée, qui (bien qu'excellente) se rapporte spécifiquement à FreeBSD.
Cette question s'applique aux services fournis par des serveurs sur des réseaux IPv4 adressés en RFC1918, qui sont rendus disponibles aux 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 alors du client vers le dispositif de passerelle, qui réécrit l'adresse de destination et l'injecte immédiatement de nouveau dans le réseau interne. C'est ce virage brusque que fait le paquet à la passerelle qui donne lieu au nom de NAT en épingle à cheveux, par analogie avec le virage en épingle à cheveux.
Le problème survient lorsque le dispositif 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 à 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 nécessitant un tel NAT de destination et qui atteignent la passerelle depuis le réseau interne, effectuer également un NAT de source (SNAT) sur le paquet entrant, généralement en réécrivant l'adresse source pour qu'elle corresponde à celle de la passerelle. Le serveur pense alors que le client est la passerelle elle-même, et lui répond directement. Cela donne à la passerelle l'occasion d'équilibrer les effets à la fois du DNAT et du SNAT sur le paquet entrant en réécrivant à la fois les adresses source et destination du paquet de retour.
Le client pense qu'il communique avec un serveur externe. Le serveur pense qu'il communique avec le dispositif de passerelle. Toutes les parties sont satisfaites. Un diagramme peut être utile à ce stade :
![entrer la description de l'image ici]()
Certains dispositifs de passerelle grand public sont assez malins pour reconnaître les paquets pour lesquels la deuxième étape du NAT est nécessaire, et ceux-ci fonctionneront probablement sans problème dans un scénario de NAT en épingle à cheveux. D'autres ne le sont pas et ne le feront donc pas, et il est peu probable qu'ils puissent être configurés pour fonctionner. Une discussion sur quels dispositifs grand public sont de telle nature est hors-sujet pour le site Server Fault.
Les dispositifs réseau appropriés peuvent généralement être configurés pour fonctionner, mais - parce qu'ils ne sont pas là pour deviner ce que veulent leurs administrateurs - ils doivent se voir dire de le faire. Linux utilise iptables pour réaliser le DNAT comme ceci :
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11
ce qui permettra un DNAT simple pour le port HTTP, vers un serveur interne sur 192.168.3.11. Mais pour activer un 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
Il est à noter que de telles règles doivent être placées correctement dans les chaînes pertinentes pour fonctionner correctement, et selon les paramètres de la chaîne filter, des règles supplémentaires peuvent être nécessaires pour permettre au trafic NAT de circuler. Toute discussion de ce genre est hors du périmètre 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 gérer le problème. La meilleure est le DNS à zones séparées, où votre organisation fournit des réponses différentes pour la recherche initiale en fonction de l'emplacement du client demandeur, soit en ayant des serveurs physiques différents pour les utilisateurs internes et externes, soit en configurant le serveur DNS pour répondre différemment en fonction de l'adresse du client demandeur.
1 votes
Si votre objectif est de tester l'accès depuis internet, il est inutile de manipuler les routes du routeur et/ou les paramètres DNS de toute façon, car au mieux, de l'intérieur, vous vérifieriez que la partie intérieure du routeur fonctionne. Je vous suggère d'utiliser un serveur proxy quelque part à l'extérieur.