On Sat, Oct 12, 2019 at 09:32:26PM +0200, Frederic Dumas wrote: > sous l'étiquette "DMZ", que se passe-t-il ? Y-a-t-il conflit uniquement si > l'adresse publique source est par malchance la même, ou bien y a-t-il > conflit dans tous les cas ?
Effectivement, l'identifiant d'une connexion TCP ou d'un flux UDP est le nexus, la combinaison des 4 valeurs (IP source, IP destination, port source, port destination). Derrière un NAT / PAT, si deux nexus sont différents, ils peuvent être les mêmes devant le NAT, vu que l'adresse IP sortante sera changée en celle du routeur/NAT/PAT -- exception: lorsqu'il y a plusieurs adresses publiques utilisables et que le NAT sait les utiliser. Une table permet de suivre les nexus connus, qu'ils correspondent à des connexions TCP ou des flux UDP, avec un timeout approprié. Le comportement de la plupart des OS de firewalls aujourd'hui est d'utiliser le nexus corrigé de l'adresse IP, mais s'il y a conflit, de changer le numéro de port émetteur par un numéro aléatoire dans une plage haute. Le nexus extérieur ainsi changé est aussi stocké dans la table. Il y a eu un autre comportement, observable chez ZyXEL et Cisco: systématiquement réécrire les numéros de ports utilisés en commençant par 1024, mais cette `sérialisation' pose de grave problèmes pour certains protocoles, donc le DNS, qui devient alors facilement `spoofable' même si les clients ont utilisé des numéros de ports source aléatoires. Un autre comportement était de systématiquement réécrire les ports internes en un numéro aléatoire dans une plage haute, il me semble aussi qu'il n'est plus utilisé. En résumé, si deux nexus sont identiques car le serveur distant, le port distant et le port local sont identiques, il faut réécriture. Que cela soit en présence de NAT/PAT statique (ce que tu appelles "DMZ") ou non. D'ailleurs, cela peut poser problèmes à certains protocoles de couche 7 qui mettent des adresses couches 3 (N) et couche 4 (P) dans leurs entêtes couche 7: tous les protocoles à enregistrement dans un annuaire (SIP p.ex.) le font. Dans ce cas, soit le NAT/PAT doit en plus corriger des entêtes couche 7 (s'ils ne sont pas signés/chiffrés), ou le protocole de couche 7, sur le client, doit tenir compte du NAT/PAT avec des protocoles comme STUN. Tout cela est facile à tester avec la commande `nc', par exemple, pour illustrer qu'un nexus doit être unique (ici pas de NAT/PAT): xterm1% nc -p 1234 193.72.186.6 80 xterm2% nc -p 1234 193.72.186.6 80 (UNKNOWN) [193.72.186.6] 80 (http) : Cannot assign requested address _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
