Là on était dans un contexte netfilter donc y'avait pas d'ambigüté sur les termes (sauf pour corrector).

oui et moi depuis le début je ne suis pas du tout dans un contexte netfilter et il veut m'y ramener a chaque fois

et meme, j'ai pas été voir le code de netfilter mais j'ose espérer qu'ils ont été malins et qu'ils ne SNAT pas les paquets qui ont déjà la bonne IP source.

RTFM

(t'es pas un peu lourd des fois ?)

En l'absence de précision sur l'origine de cette invention, j'en déduis que c'était bien une pure invention.

(D'ailleurs j'ai déjà oublié de quoi on parlait.)

Attention : déjà Source-NAT implique PAT!

C'est ça que tu n'as pas l'air de voir.

depuis le début c'est clair pour moi qu'il y a du PAT.

Si tu crois que SNAT ça veut juste dire "avoir une certaine IP source en sortie", c'est que tu es bien loin de saisir la complexité effarante de SNAT.

Je vois vraiment pas ou mon raisonnement coince et ou le tiens serait valide. la complexité de SNAT n'a rien avoir la dedans.

tu consideres peut-etre que le traffic partant du routeur a pour source l'adresse ip LAN du routeur (donc privée) et doit etre aussi SNAT-ée ? ca c'est sur mais c'est pas de ca qu'on parle non ?

ou que pour éviter des conflits de ports tout doit etre rePATer dans le module SNAT ?! (ce qui n'est pas le cas si le code SNAT est bien concu).

sinon je vois pas. vraiment. un exemple peut-être ?

moi mon exemple c'est VMWare Player par exemple qui arrive à faire causé ma MV (configurée NAT) avec la même IP que mon poste sans pourtant que tout mon traffic réseau passe par VMWare Player ...

hum c'est clair maintenant que tu generalises l'implèmentation et les concepts linuxiens a des notions plus universelles.

Netfilter c'est tres generique, trop peut-etre. c'est surtout concu pour le firewall et pour etre 'hookable' donc ca veut voir et suivre tout les paquets qui passent.

on peut tres bien faire un module SNAT tout simplement en réservant un bloc de ports (d'un coup ou a la demande) et en gérant dedans la translation et le suivis des ports (le conntrack) sans pour autant devoir prendre la main sur l'interface de sortie (on est juste un processus qui cause sur cette interface tout comme un navigateur internet est un autre processus qui cause sur la même interface avec la meme IP).

c'est qu'une histoire d’implèmentation, faut vraiment pas generaliser le cas particulier de netfilter.

non VMWare player ne fait pas de firewall. il fait juste du SNAT entre la VM et le réseau de l'hote.
Firewall et SNAT sont des notions et concepts distincts même si souvent leur implèmentation utilisent des choses communes (la encore ne pas confondre implèmentations et concepts)

Pour en revenir a l'origine du débat. Un routeur bien conçu peut donc faire du SNAT et peut aussi gérer un tunnel 6rd sans que les paquets 6rd subissent un traitement SNAT. Je presume meme que netfilter sait faire ca sinon ca serait un gros gachi...

Elles m’inquiètent tes 1ere et dernière questions...
VMWare Player est une application tout comme Chrome ou Firefox, ni plus, ni moins. Elle peut donc ouvrir sans probleme tout type de connections IP en TCP ou UDP.

"netstat -t" ?! c'est pas trop standardisé '-t' comme option (encore une fois y'a pas que Linux en réseau, loin de la).
"netstat -t" sous Windows ca affiche l'état du TCP Chimney Offload, sous certains Unix l'option -t n'existe pas ou sous d'autres c'est un raccourci pour l'option -tcp.
Donc je presume -tcp ?
quoiqu'il en soit oui, on voit les connections IP (tcp et udp) de VMWare avec netstat.