Si tu effectues du portforwarding sur le même réseau, tu devras
t'assurer que les paquets futurs et leurs réponses passeront par la
machine NAT (pour qu'ils soient modifiés). Le code NAT (depuis
2.4.0-test6), va bloquer les ICMP redirect sortants qui sont
produits lorsque le paquet NATé sort par la même interface que
celle par laquelle il est rentré, mais le serveur distant
continuera toujours à essayer de répondre directement au client
(qui ne reconnais pas la réponse).
Le cas classique est lorsque le staff interne essaye d'accèder
ton serveur web `public', qui est DNATé de l'adresse publique
(1.2.3.4) vers une machine interne (192.168.1.1), comme ceci :
Une solution est d'utiliser un serveur DNS interne qui connait
l'adresse IP réelle de ton site web public, et de passer toutes les
autres requètes vers un serveur DNS externe. Ceci veut dire que le
logging sur le serveur web montrera les adresses IP interne
correctement.
L'autre solution est d'avoir la machine NAT qui mappe aussi les
adresses IP sources sur la sienne pour ces connections, trompant le
serveur en répondant par elle. Dans cet exemple, nous devrions
faire ceci (en supposant que l'adresse IP interne de la machine NAT
est 192.168.1.250):
A cause de la règle de PREROUTING, les paquets seront
déja destinés pour le serveur web interne : nous pouvons dire
lesquels sont sourcés en interne par les adresses IP source.