On ne le répètera jamais assez : le NAT (dont le masquerading est une forme) casse la connectivité IP de bout en bout qui est un des fondement du protocole IP et dont certains protocoles complexes comme SIP ou FTP ont besoin, sous peine d’être cassés en même temps.
Si tu veux persister avec du NAT, essaie de charger les modules de suivi de connexion et de NAT de netfilter pour le protocole SIP (nf_conntrack_sip et nf_nat_sip) sur la machine qui fait le masquerading. La fonction de ces modules et d’analyser les flux SIP et de faire les modifications nécessaires pour tenir compte du NAT. C’est de la bidouille compliquée, mais c’est mieux que rien.
L’idéal serait de supprimer ce NAT et d’ajouter une route de retour vers T sur S, mais tu dis qu’on ne peut rien modifier sur S, dommage. Néanmoins si S et M ont une passerelle par défaut commune qui est suffisamment configurable, tu peux ajouter la route de retour sur celle-ci. Le routage de retour de S vers T ne sera pas optimal puisqu’il passera par la passerelle puis par M (sauf si la passerelle émet des ICMP Redirect et S les accepte) mais AMA c’est mieux que du NAT.
Une autre possiblité, puisque tu utilises un tunnel en mode tap, est de ponter l’interface tap de M avec l’interface ethernet du réseau local et d’attribuer à l’interface tap de T une adresse dans le réseau local qui sera joignable directtement par S.
Une autre possibilité, mais moins propre, est d’attribuer à T une adresse dans le réseau local et d’activer le proxy ARP sur l’interface ethernet de M, ainsi S verra T comme s’il était sur le réseau local.
