Pourquoi les entreprises n'utilisent-elles pas davantage de solutions NAT internes ou similaires pour autoriser les épingles à cheveux NAT?

Le NAT de l'intérieur à l'intérieur, également appelé bouclage NAT, résout les problèmes NAT en épingle à cheveux lors de l'accès à un serveur Web sur l'interface externe d'un ASA ou d'un périphérique similaire à partir d'ordinateurs sur l'interface interne. Cela empêche les administrateurs DNS d'avoir à maintenir une zone DNS interne en double qui a les adresses RFC1918 correspondantes pour leurs serveurs qui sont NATted aux adresses publiques. Je ne suis pas ingénieur réseau, donc je manque peut-être quelque chose, mais cela semble être une évidence à configurer et à mettre en œuvre. Le routage asymétrique peut être un problème mais est facilement atténué.

D'après mon expérience, les administrateurs / ingénieurs réseau préfèrent que les systèmes exécutent simplement des split-dns plutôt que de configurer leurs pare-feu pour gérer correctement les épingles à cheveux NAT. Pourquoi est-ce?

Il y a quelques raisons pour lesquelles je ne le ferais pas:

• Pourquoi mettre une pression supplémentaire sur les routeurs DMZ et le pare-feu si vous n'en avez pas besoin? La plupart de nos services internes ne se trouvent pas dans la zone démilitarisée mais dans le secteur général de l'entreprise, avec des services de mandataire dans la zone démilitarisée pour un accès à distance occasionnel. Faire de l'intérieur vers l'intérieur ajoute plus de charge à la DMZ, ce qui dans notre cas serait important.
• Si vous ne faites pas DNAT + SNAT, vous obtiendrez un routage asymétrique, ce qui est notoirement difficile à obtenir correctement. Donc, vous SNAT et perdez les informations IP source. Cependant, il est extrêmement utile de lier des adresses IP source à des personnes à des fins de dépannage. Ou parfois nerfshooting en cas de stupidité. "Hé, cette IP fait quelque chose de bizarre sur le service non authentifié X" "Oh, regardons dans les journaux du serveur imap qui c'est".

Évidemment, il ne peut y avoir de réponse définitive à cela, mais je pourrais penser à un certain nombre de raisons:

1. Élégance: NAT n'est pas très élégant pour commencer, mais une nécessité avec l'espace d'adressage restreint d'IPv4. Si je peux éviter le NAT, je le ferai. Avec IPv6, le problème disparaît de toute façon.
2. Complexité: en particulier dans le cas où vous n'avez pas un seul routeur «cœur» créant toutes vos limites de sécurité, les configurations de filtre peuvent devenir assez délicates. Soit cela, soit vous devrez répartir et maintenir les règles NAT sur presque tous vos périphériques de routeur.
3. Référence: partout où les administrateurs de pare-feu sont des gens différents du reste de l'équipe d'administration du serveur, ils peuvent être difficiles à atteindre. Afin de s'assurer que les changements ne soient pas retardés par le backlog (ou les vacances) de l'administrateur du pare-feu, l'option de garder la responsabilité dans la même équipe est choisie
4. Portabilité et pratique courante: L'utilisation des vues DNS est "juste ce que tout le monde sait que c'est fait" pour résoudre ce problème. Tous les routeurs limites ne prendraient pas en charge le bouclage NAT de manière simple, moins de personnes sont susceptibles de savoir comment le configurer correctement dans votre environnement spécifique. Lors du dépannage de problèmes de réseau, l'équipage devrait être conscient de la configuration NAT en épingle à cheveux et de toutes ses implications - même lorsqu'il cherche un problème apparemment sans rapport.

Avis de non-responsabilité - c'est une réponse aux appâts enflammés

Une raison courante pour laquelle je pense que des solutions comme celle-ci sont évitées est une peur / haine irrationnelle du NAT de la part des ingénieurs réseau . Si vous souhaitez voir des exemples de discussion à ce sujet, consultez-les:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (le blog de Tom semble continuer d'attirer des discussions NAT / IPv6 plutôt ferventes)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (mon blog)

D'après ce que je peux dire, une grande partie de cette peur provient des mauvaises implémentations de Cisco de NAT (donc en ce sens, cela peut ne pas être irrationnel), mais à mon avis, l'ingénieur réseau "classique" est si bien formé dans le "NAT est mauvaise "vision du monde, qu'il ou elle ne peut pas voir des exemples évidents comme celui-ci où cela est parfaitement logique et simplifie réellement la solution.

Voilà, revenez au contenu de votre cœur! :-)

Ma conjecture est:

1. Le DNS partagé est plus facile à comprendre.
2. NAT Hairpin utilise des ressources sur le routeur, contrairement à split-dns.
3. Les routeurs peuvent avoir des limitations de bande passante que vous n'obtenez pas à travers une configuration split-dns.
4. Split-dns sera toujours plus performant en évitant les étapes de routage / NAT.

Du côté positif pour l'épingle à cheveux NAT,

• Une fois installé, cela fonctionne.
• Aucun problème avec les caches DNS pour les ordinateurs portables ne s'est déplacé entre le réseau professionnel et Internet public.
• Le DNS pour un serveur n'est géré qu'en un seul endroit.

Pour un petit réseau avec des exigences de trafic faibles vers un serveur interne, j'opterais pour le NAT en épingle à cheveux. Pour un réseau plus grand avec de nombreuses connexions au serveur et où la bande passante et la latence sont importantes, optez pour split-dns.

De mon point de vue, cela a changé un peu entre la transition de Cisco Pix à ASA. J'ai perdu la aliascommande. Et en général, l'accès à l'adresse extérieure à partir de l'interface intérieure sur un pare-feu Cisco nécessite une sorte de ruse. Voir: Comment puis-je atteindre mon serveur interne sur l'IP externe?

Cependant, nous n'avons pas toujours besoin de conserver une zone DNS interne en double. Cisco ASA peut rediriger les requêtes DNS pour les adresses externes vers des adresses internes si elles sont configurées sur l'instruction NAT. Mais je préfère garder une zone interne pour la zone DNS publique afin d'avoir cette granularité et de pouvoir gérer cela en un seul endroit plutôt que de passer au pare-feu.

En règle générale, seuls quelques serveurs peuvent nécessiter cela dans un environnement (messagerie, Web, quelques services publics), donc cela n'a pas été un problème énorme.

Je peux penser à quelques raisons:

1. De nombreuses organisations ont déjà divisé le DNS parce qu'elles ne souhaitaient pas publier toutes leurs informations DNS internes dans le monde, il n'est donc pas beaucoup d'efforts supplémentaires pour gérer les quelques serveurs qui sont également exposés via une adresse IP publique.
2. À mesure qu'une organisation et son réseau se développent, ils séparent souvent les systèmes desservant les personnes internes des serveurs desservant les externes, de sorte que le routage vers les externes pour une utilisation interne peut être un chemin réseau beaucoup plus long.
3. Moins les périphériques intermédiaires apportent de modifications aux paquets, mieux c'est en termes de latence, de temps de réponse, de charge des périphériques et de dépannage.
4. (très mineur, certes) Il existe des protocoles que NAT cassera toujours si le périphérique NATing ne va pas au-delà des en-têtes du paquet et ne modifie pas les données qu'il contient avec la ou les nouvelles adresses IP. Même si ce n'est qu'un cas de mémoire institutionnelle, c'est toujours une raison valable pour les gens de l'éviter, surtout s'ils ont affaire à un protocole dont ils ne sont pas sûrs à 100%.

Si je devais utiliser le bouclage NAT, je serais un peu inquiet de savoir comment le périphérique NAT traitera les adresses sources usurpées. S'il ne vérifie pas quelle interface le paquet est entré, alors je pourrais usurper les adresses internes du WAN et envoyer des paquets au serveur avec des adresses internes. Je n'ai pas pu obtenir de réponses, mais je pourrais peut-être compromettre le serveur en utilisant une adresse interne.

Je voudrais configurer le bouclage NAT, me connecter au commutateur DMZ et envoyer des paquets avec des adresses de source interne falsifiées. Vérifiez le journal du serveur pour voir s'ils ont été reçus. Ensuite, j'allais au café pour voir si mon FAI bloquait les adresses usurpées. Si je trouvais que mon routeur NAT ne vérifiait pas l'interface source, je n'utiliserais probablement pas le bouclage NAT même si mon FAI vérifie.