[gull] Double NAT

Marc SCHAEFER schaefer at alphanet.ch
Sun Oct 13 08:33:25 CEST 2019


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



More information about the gull mailing list