Bonjour Adrien, Énormément d'entreprises utilisent le double nat sur la chaine d'accès à internet. Exemple Français: la majorité des banques utilisent des IP publiques d'autrui en interne. Certaines uniquement pour les agences / campus, d'autres également pour leur DC...
En général la majorité des structures de plus de 100k personnes et avec un historique lourd (achats, filiales,...) s'est déjà retrouvée au pied du mur. Faire du double NAT impose de centraliser la chaine d'accès internet pour l'ensemble du groupe ou d'obliger à ce que le design de cette chaine soit reproduit à l'identique si des filiales veulent leur propre accès par exemple. Typiquement, on chaine 2 lots de proxy (interne et externe) Les 2 lots se voient entre eux via des IP 1918 Le lot interne est exposé aux clients via du privé ou du faux public, pas d'importance. Le lot externe exploite de vrais IP publiques pour aller sur le web (sauf si on re nat encore l'exposition externe du proxy, ce qui est rare...), ce lot externe n'a aucune route vers le réseau interne, en dehors des proxy internes et de réseaux de management et supervision. Pour exposer des serveurs à l'extérieur, même bricolage, on double NAT (par exemple FW en entrée DMZ puis 2nde fois sur des SLB) Certaines entreprises n'ont pas pris de précautions, et ont dû mettre en œuvre ce double chainage un beau jour en urgence. D'ailleurs quand cloudflare a sorti son 1.1.1.1, certains ont découvert qu'ils routaient déjà cette IP en interne, car elle a longtemps été hard codé dans les WLC wifi Cisco. Chez les habitués de ce bricolage, on tape souvent dans les IP du DoD US, sauf que celui-ci indique dans divers documents passés au congrès qu'ils veulent vendre une bonne partie de leur IP publiques dans la dizaine d'année qui vient. En vérité ça ne devrait pas se faire beaucoup plus vite que leur nombreuses tentatives de migration vers IPv6. Nouveau problème aujourd'hui, ces grandes entreprises commencent à devoir annoncer de vraies IP publiques dans leur backbone interne (par exemple pour faire du MS Teams en UDP via des G-IX, ce qui est plus performant qu'en TCP) Mais si demain MS utilise une IP qui existe en interne ? ... et MS annonce les nouvelles IP et URL Office 365 seulement 4 à 6 semaines à l'avance. Idéalement les adeptes du "bricolage double nat" vont donc devoir lancer un script chaque semaine pour vérifier qu'aucune de leur fausse IP publique n'est nouvellement affectée dans le monde réel à l'AS de leur provider préféré (MS, Amazon, ...) histoire de déclencher l'alerte tsunami à temps (oxymore power) Et notre ami l'UDP qui force la main pour teams, il arrive à grands pas grâce à QUIC, dans quelque temps on interrogera plein d'API publiques ou de ressources cloud via QUIC, et bien sûr on naviguera avec, les équipes pare-feu et backbone vont alors pouvoir partager l'apéro avec les équipes proxy... Quic a bien un connection ID, mais il sert à la mobilité et n'est pas visible des middlebox... Ha, et si tu comptes faire du split tunneling avec le VPN, il faut veiller à surveiller le non-recouvrement de la même façon que pour les vraies routes publiques apprises en backbone. (pour du SaaS en général) Une raison plus de s'intéresser à IPv6 dans les grosses structures, sauf si on veut garder un réseau qui ressemble à un film de Christopher Nolan. Concernant le NAT-DNS dont tu parles, il est utile pour exposer un serveur d'une entité A à une entité B avec de l'overlapp. Le principal intérêt étant que certaines solutions (F5, Palo,..) permettent de tout gérer sur la même appliance de façon consistante, car toute la "truanderie" nat et dns hérite de la même règle sur la même boite, et qu'il n'y a donc pas besoin de demander à l'administrateur DNS et aux équipes FW etc de se synchroniser. C'est extrêmement utilisé, notamment quand les structures A et B n'ont plus trop de comptes à se rendre, mais que la force des choses les oblige à collaborer. Ce mode limite fortement les interactions nécessaires et le nombre de gestes à droite et gauche. Reste un cas qui pose problème, le SIP. Il y'a bien des ALG pour natter aussi l'intérieur de la signalisation SIP, mais bon... On va vers un monde où on aura de meilleures performances à la maison (IPv6 + QUIC) qu'au bureau (NAT + TCP) pour tout ce qui est web, que ça soit application, appels API,... Une sorte d'apartheid protocolaire que certains utilisateurs de Saas et leur direction ont déjà noté grâce au confinement. Jean-Charles Bisecco --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
