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


22

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?


Peut-être parce que les vues DNS sont plus faciles à dépanner?
NickW

2
Peut-être, mais lorsque vous utilisez DNS sur des contrôleurs de domaine AD (un scénario courant), les vues n'existent pas.
MDMarra

2
Pourquoi auriez-vous besoin de publier votre zone AD sur Internet? Si votre AD est ad.example.comou similaire (comme il se doit !), Ce problème existera pour toutes les example.comentrées DNS publiques et rien en interne n'est publié en externe. Bien sûr, si vous avez nommé votre AD de la même manière que votre présence publique, vous devez utiliser le DNS partagé, mais ce n'est pas une conception AD de meilleure pratique.
MDMarra

5
J'ajouterais que les vues DNS ne sont plus faciles à dépanner que si les clients ne se déplacent jamais entre eux . Les choses peuvent mal tourner lorsque les clients prennent un résultat interne mis en cache à l'extérieur.
LapTop006

3
Les clients ne doivent pas mettre en cache les réponses DNS, c'est à cela que servent les serveurs DNS . Je sais que Windows aime beaucoup le cache silencieux (et mortel), mais c'est l'une des nombreuses raisons pour lesquelles je pense qu'il est impropre à la production.
MadHatter prend en charge Monica

Réponses:


11

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".

2
Juste une note, si votre pare-feu fait du routage L3 et que vos itinéraires pour vos clients externes et internes font un bond au pare-feu, vous ne devriez pas avoir à vous soucier du routage asymétrique, non?
MDMarra

12

É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.

1
1. Dans cette situation, le NAT est utilisé de toute façon. Cela n'ajoute pas de NAT là où il n'y en avait pas avant 2. Dans mon exemple, ils sont tous gérés par le même périphérique ou groupe de périphériques. 4. Comme indiqué dans mon commentaire ci-dessus, un scénario très courant utilise des contrôleurs de domaine AD pour DNS en interne. Le DNS Windows ne prend pas en charge les vues. En outre, j'ai constaté que la plupart des firmwares de routeur / pare-feu quelque peu modernes prennent en charge l'épingle à cheveux NAT d'une manière ou d'une autre.
MDMarra

1
@MDMarra quelques remarques: 1. - "il y aurait une bizarrerie NAT de moins à se soucier" est ce que je voulais dire, 2. - votre question ne le dit pas explicitement, mais avec un seul routeur, il sera évidemment plus facile à gérer , 4. avec le DNS interne en place qui est obligatoire pour tous les clients, vous n'avez pas besoin de vues - vous créez simplement une zone interne et obtenez le même effet que vous l'avez mentionné dans votre question, le raisonnement ci-dessus s'applique toujours.
le-wabbit

1
Mais quelle bizarrerie NAT? Quel comportement spécifique cela introduirait-il qui pose problème? J'ai travaillé dans une université qui avait configuré l'épingle à cheveux NAT sur un cluster Netscreen pour plus de 100 hôtes externes et nous n'avons jamais eu de problème.
MDMarra

Notez également que l'utilisation du NAT en épingle à cheveux dans ce scénario la fait ressembler davantage à la solution IPv6, car sous IPv6, le système aura une adresse accessible mondialement; l'épingle à cheveux NAT simule ce comportement.
Paul Gear

@MDMarra la "bizarrerie NAT" la plus remarquable pour le cas "NAT en épingle à cheveux" serait le chemin de routage non optimal, ce qui signifie que les paquets réécrits devraient parcourir la majeure partie du chemin de retour. Voir cela dans un vidage de paquets lors du dépannage de la connectivité est au mieux source de confusion. Je crois que d'autres ont déjà mentionné le problème de routage asymétrique dans leurs réponses, qui est lié. Il ne fait aucun doute que vous pouvez le faire fonctionner très bien. Mais cela ne vaut pas l'effort dans la majorité des cas OMI.
le-wabbit

7

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:

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! :-)


1
Je ne sais pas si je considérerais cela comme une peur irrationnelle. L'expérience m'a appris que le NAT peut casser ou faire des choses étranges avec beaucoup de choses.

1
@Kce Mais si vous utilisez déjà NAT sur votre interface externe, quelle différence fait la configuration du bouclage NAT?
MDMarra

@MDMarra - Aucun vraiment. J'étais en train de faire le point plutôt pédant que parfois la peur de l'équipe des services réseau de NAT n'est pas irrationnelle.

Je n'ai pas peur du NAT, je le déteste.
Michael Hampton

1
Publication modifiée pour inclure la haine. :-)
Paul Gear

3

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.


2

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.


Est-ce une ruse si elle est prise en charge et documentée par Cisco ? Bien sûr, c'est un peu plus de travail, mais cela rend-il difficile ou hacky?
MDMarra

Tromperie, en ce sens que les gens ne savent pas / s'attendent / n'y pensent pas s'ils ne le savent pas déjà. C'est une question courante: comment puis-je atteindre une adresse IP externe de l'intérieur de mon pare-feu Cisco .
ewwhite

Typically, there are only a few servers that may require this within an environmentpeut-être dans certains endroits, mais j'ai travaillé dans une université avec plus de 100 serveurs / appareils dans une DMZ et j'ai également travaillé chez un fournisseur de tests / certification avec plus de 40 serveurs répartis sur trois DMZ. Pour les petites entreprises, vous ne pouvez avoir qu'un ou deux serveurs exposés à l'extérieur, mais ce n'est pas nécessairement le cas pour tout le monde.
MDMarra

Si les serveurs sont dans une zone démilitarisée, c'est moins un problème, non?
ewwhite

Dans ce cas, "DMZ" signifie connecté à l'interface externe dudit pare-feu avec des règles de refus par défaut entre les zones en place.
MDMarra

2

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%.

0

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.


Désolé, je comprends peut-être mal ce que vous dites, mais les adresses RFC1918 ne sont pas acheminées sur Internet, donc je ne vois pas ce que cela peut faire d'essayer de les usurper sur le WAN. Ils ne feront même pas le premier saut.
MDMarra

L'adresse de destination est l'adresse publique du NAT sur le port mappé au serveur. L'adresse source est l'une des adresses IP privées à l'intérieur du NAT. Les adresses source ne sont pas utilisées dans le routage et ne sont pas vérifiées par tous les routeurs publics. La seule différence avec une requête interne légitime est que le paquet provient du WAN.
Kent England
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.