oui,
sauf que la nat est un peut plus intelligente que ça .. heureusement .
tu ne rediriges pas le port 80, pourtant ça marche aussi:
la connexion tcp commence bien avant l'envoi du LO : les bits syn ont déjà créé la connexion.
faisons le schéma:
une connexion sortante du réseau privé:
source ip privée est transformée en source ip publique par nat .
port source privé est modifié en port source public (tartempion).
ces 2 modifications sont enregistrées dans la table nat.
les adresses et port destination sont corrects eux (adresse=smt.free.fr et port = 25).
se serveur free répond à ip publique / port tartempion (enregistré dans la table) en adresses/port destination, la fonction nat relit la table pour remettre adresse dest et port corrects vers le bon destinataire les adresses/port source sont les m^mes que destination dans le paquet syn précédent dans l'autre sens.
A ce moment là, la table est créée dynamiquement et chaque paquet sortant modifie add source et chaque entrant modifie destination en sens inverse.
la table:
iplocale_source+portlocal<=>ippublique_destination+portpublic.
le probléme est dans l'autre sens: un connexion venant du net: la table n'est pas créée:
l'association ip publiquedestibnation+ port public ne pointe sur rien.
d'où le port mapping pour créer staiquement une entrée dans la table:
add privée+port privé<=>adresse publique+port public.
je sais, c'est pas bien clair comme ça, j'avais une autre illustration, mais je ne sais pas ce que j'en ai fait.
j'ai bien ça :
http://fr.wikipedia.org/wiki/NAT