Por que mais organizações não usam NAT de dentro para dentro ou soluções similares para permitir grampos de cabelo NAT?


22

O NAT de dentro para dentro, também conhecido como loopback do NAT, resolve problemas de NAT em gancho de cabelo ao acessar um servidor da Web na interface externa de um ASA ou dispositivo semelhante a partir de computadores na interface interna. Isso evita que os administradores de DNS mantenham uma zona DNS interna duplicada que possua os endereços RFC1918 correspondentes para seus servidores que tenham NAT para endereços públicos. Como não sou engenheiro de rede, talvez esteja faltando alguma coisa, mas isso parece um acéfalo para configurar e implementar. O roteamento assimétrico pode ser um problema, mas é facilmente mitigado.

Na minha experiência, os administradores / engenheiros de rede preferem que os funcionários do sistema executem split-dns em vez de configurar seus firewalls para lidar adequadamente com grampos de cabelo NAT. Por que é isso?


Talvez porque as visualizações de DNS sejam mais fáceis de solucionar problemas?
21313 NickW

2
Possivelmente, mas ao usar o DNS nos controladores de domínio do AD (um cenário comum), não existem exibições.
MDMarra

2
Por que você precisaria publicar sua zona do AD na Internet? Se o seu AD for ad.example.comsemelhante ou similar (como deveria ser!), Esse problema existirá para todas as example.comentradas DNS públicas e nada interno será publicado externamente. Obviamente, se você tiver nomeado seu AD igual à sua presença pública, deverá usar o DNS dividido, mas esse não é o melhor design do AD.
MDMarra 17/05/2019

5
Eu acrescentaria que as visualizações de DNS são mais fáceis de solucionar se os clientes nunca se moverem entre elas . As coisas podem dar errado quando os clientes obtêm um resultado interno em cache para fora.
LapTop006

3
Os clientes não devem armazenar em cache as respostas DNS, é para isso que servem os servidores DNS . Sei que o Windows gosta muito de cache silencioso (e mortal), mas essa é uma das muitas razões pelas quais acho inadequado para uso em produção.
MadHatter apoia Monica

Respostas:


11

Existem algumas razões pelas quais eu não faria isso:

  • Por que sobrecarregar os roteadores DMZ e o firewall, se você não precisa? Muitos dos nossos serviços internos não estão na DMZ, mas na área corporativa geral, com serviços de proxy na DMZ para acesso remoto ocasional. Fazer nat de dentro para dentro adiciona mais carga à DMZ, o que, no nosso caso, seria significativo.
  • Se você não fizer DNAT + SNAT, receberá roteamento assimétrico, o que é notoriamente complicado de acertar. Então você SNAT e perde informações de IP de origem. No entanto, é muito útil vincular IPs de origem a pessoas para fins de solução de problemas. Ou ocasionalmente nerfshooting fins em casos de estupidez. "Ei, esse IP está fazendo algo complicado no serviço não autenticado X" "Oh, vamos ver nos registros do servidor imap quem é".

2
Apenas uma observação, se o seu firewall estiver executando o roteamento L3 e você tiver suas rotas para seus clientes externos e internos, eles não devem se preocupar com o roteamento assimétrico, certo?
MDMarra 21/05

12

Obviamente, não pode haver uma resposta definitiva para isso, mas eu poderia pensar em várias razões:

  1. Elegância: o NAT não é muito elegante, mas uma necessidade do espaço de endereço restrito do IPv4. Se eu puder evitar o NAT, eu irei. Com o IPv6, o problema está desaparecendo de qualquer forma.
  2. Complexidade: especialmente nos casos em que você não possui apenas um roteador "núcleo" criando todos os seus limites de segurança, as configurações de filtro podem se tornar bastante complicadas. Ou você teria que espalhar e manter as regras NAT em quase todos os dispositivos do roteador.
  3. Referência: onde quer que os administradores de firewall sejam pessoas diferentes do restante da equipe de administração de servidores, eles podem ser difíceis de alcançar. Para garantir que as alterações não sejam adiadas pelo backlog (ou férias) do administrador do firewall, é escolhida a opção de manter a responsabilidade na mesma equipe
  4. Portabilidade e prática comum: o uso de visualizações DNS é "exatamente o que todos sabem que é feito" para resolver esse problema. Nem todo roteador de limite suportaria NAT de loopback de maneira direta, menos pessoas provavelmente saberão como configurá-lo corretamente em seu ambiente específico. Ao solucionar problemas de rede, a equipe precisa estar ciente da configuração NAT hairpin e de todas as suas implicações - mesmo quando está procurando um problema aparentemente não relacionado

1
1. Nesta situação, o NAT está sendo usado de qualquer maneira. Isso não está adicionando NAT onde não havia NAT antes do 2. No meu exemplo, eles são todos tratados pelo mesmo dispositivo ou cluster de dispositivos. 4. Conforme afirmado no meu comentário acima, um cenário muito comum é o uso interno de controladores de domínio do AD para DNS. O DNS do Windows não oferece suporte a visualizações. Além disso, eu descobri que os firmware de firewall / roteador mais modernos suportam hairpinning de uma maneira ou de outra.
MDMarra

1
@MDMarra algumas observações: 1. - "haveria menos estranheza de NAT para se preocupar" é o que eu basicamente quis dizer, 2. - sua pergunta não diz explicitamente, mas com apenas um roteador, obviamente será mais fácil lidar com isso. , 4. com o DNS interno, obrigatório para todos os clientes, você não precisa de visualizações - você apenas criaria uma zona interna e obteria o mesmo efeito mencionado na sua pergunta, o raciocínio acima ainda se aplica.
the-wabbit

1
Que estranheza NAT, no entanto? Que comportamento específico isso introduziria que causa problemas? Eu trabalhei em uma universidade que tinha hairpinning NAT configurado em um cluster Netscreen para mais de 100 hosts externos e nunca tivemos um problema.
MDMarra

Observe também que o uso de hairpin NAT nesse cenário está na verdade parecendo mais com a solução IPv6, porque no IPv6 o sistema terá um endereço alcançável globalmente; hairpin NAT simula esse comportamento.
Paul Gear

@MDMarra, a mais extraordinária "estranheza NAT" para o caso "hairpin NAT" seria o caminho de roteamento não ideal, o que significa que os pacotes reescritos teriam que percorrer a maior parte do caminho de volta. Ver isso em um despejo de pacotes ao solucionar problemas de conectividade é, na melhor das hipóteses, confuso. Acredito que outros já tenham mencionado a questão do roteamento assimétrico em suas respostas, o que está relacionado. Não há dúvida de que você pode fazê-lo funcionar bem. Mas não vale a pena o esforço na maioria dos casos da IMO.
the-wabbit

7

Isenção de responsabilidade - esta é uma resposta inflamada.

Um motivo comum para que soluções como essa sejam evitadas é um medo / ódio irracional do NAT por parte dos engenheiros de rede . Se você quiser ver alguns exemplos de discussão sobre isso, confira estes:

Pelo que posso dizer, muito desse medo decorre das implementações ruins do NAT da Cisco (portanto, nesse sentido, pode não ser irracional), mas, na minha opinião, o engenheiro de rede "clássico" é tão instruído no "NAT é visão de mundo ruim ", de que ele ou ela não pode ver exemplos óbvios como este, onde faz todo o sentido e realmente simplifica a solução.

Lá vai você - voto negativo para o conteúdo do seu coração! :-)


1
Não sei se consideraria um medo irracional. A experiência me ensinou que o NAT pode quebrar ou fazer coisas estranhas com muitas coisas.

1
@ Kce Mas se você já está usando o NAT na sua interface externa, que diferença faz a configuração do loopback do NAT?
MDMarra 21/05

@MDMarra - Nenhum realmente. Estou afirmando que, às vezes, o medo da equipe de serviços de rede do NAT não é irracional.

Não tenho medo do NAT, odeio.
Michael Hampton

1
Postagem editada para incluir o ódio. :-)
Paul Gear

3

Meu palpite é:

  1. O DNS dividido é mais fácil de entender.
  2. O Hairpin NAT usa recursos no roteador, enquanto o split-dns não.
  3. Os roteadores podem ter limitações de largura de banda que você não obtém através de uma configuração de DNS dividido.
  4. O Split-DNS sempre terá um desempenho melhor, pois você evita as etapas de roteamento / NAT.

No lado positivo do NAT hairpin,

  • Uma vez configurado, ele simplesmente funciona.
  • Não há problemas com os caches DNS para laptops movidos entre a rede de trabalho e a Internet pública.
  • O DNS de um servidor é gerenciado apenas em um local.

Para uma pequena rede com pouco tráfego para um servidor interno, eu utilizaria NAT hairpin. Para uma rede maior com muitas conexões com o servidor e onde a largura de banda e a latência são importantes, use DNS dividido.


2

Na minha perspectiva, isso mudou um pouco entre a transição do Cisco Pix para o ASA. Perdeu o aliascomando. E, em geral, acessar o endereço externo a partir da interface interna em um firewall da Cisco requer algum tipo de truque. Consulte: Como faço para acessar meu servidor interno no IP externo?

Porém, nem sempre precisamos manter uma zona DNS interna duplicada. O Cisco ASA pode redirecionar consultas DNS para endereços externos para endereços internos, se configurado na instrução NAT. Mas eu prefiro manter uma zona interna da zona DNS pública para ter essa granularidade e poder gerenciar isso em um só lugar, em vez de avançar para o firewall.

Normalmente, existem apenas alguns servidores que podem exigir isso em um ambiente (correio, web, alguns serviços públicos), portanto, esse não foi um tremendo problema.


É complicado se é suportado e documentado pela Cisco ? Claro que é um pouco mais trabalhoso, mas isso o torna complicado ou hacky?
MDMarra 17/05/2019

Trapaça, na medida em que as pessoas não sabem / esperam / pensam nisso se ainda não estão cientes. É uma pergunta comum: como faço para alcançar um IP externo de dentro do meu firewall da Cisco .
ewwhite 17/05

Typically, there are only a few servers that may require this within an environmenttalvez em alguns lugares, mas trabalhei em uma universidade com mais de 100 servidores / dispositivos em uma DMZ e também trabalhei em um provedor de testes / certificação com mais de 40 servidores espalhados por três DMZs. Para empresas menores, você pode ter apenas um ou dois servidores expostos ao exterior, mas esse não é necessariamente o caso para todos.
MDMarra

Se os servidores estiverem em uma DMZ, isso é menos problemático, certo?
Ewhite 17/05

Nesse caso, "DMZ" significa conectado à inferface externa do referido firewall com regras de negação padrão entre as zonas em vigor.
MDMarra 17/05/2019

2

Eu posso pensar em alguns motivos:

  1. Muitas organizações já dividiram o DNS por não quererem publicar todas as informações internas do DNS no mundo, portanto, não há muito esforço adicional para lidar com os poucos servidores que também são expostos por meio de um IP público.
  2. À medida que uma organização e sua rede crescem, elas geralmente separam os sistemas que atendem às pessoas internas dos servidores que atendem às externas, portanto, o roteamento para os externos para uso interno pode ser um caminho de rede muito mais longo.
  3. Quanto menos modificações os dispositivos intermediários fizerem nos pacotes, melhor será a latência, o tempo de resposta, a carga do dispositivo e a solução de problemas.
  4. (muito menor, é certo) Existem protocolos que o NAT ainda quebrará se o dispositivo de NATing não ultrapassar os cabeçalhos do pacote e modificar os dados nele com os novos endereços IP. Mesmo que seja apenas um caso de memória institucional, ainda é um motivo válido para as pessoas evitá-lo, especialmente se estiverem lidando com um protocolo sobre o qual não estão 100% certos.

0

Se eu fosse usar o loopback NAT, ficaria um pouco preocupado com o modo como o dispositivo NAT manipulará endereços de origem falsificados. Se ele não verificar em qual interface o pacote chegou, eu poderia falsificar endereços internos da WAN e enviar pacotes ao servidor com endereços internos. Não consegui obter respostas, mas posso comprometer o servidor usando um endereço interno.

Eu configuraria o loopback NAT, conectaria o switch DMZ e enviaria pacotes com endereços de origem internos falsificados. Verifique o log do servidor para ver se eles foram recebidos. Então eu iria ao café e veria se meu provedor de serviços de Internet está bloqueando endereços falsificados. Se eu descobrisse que meu roteador NAT não estava verificando a interface de origem, provavelmente não usaria o loopback NAT, mesmo que meu ISP estivesse verificando.


Desculpe, posso estar entendendo mal o que você está dizendo, mas os endereços RFC1918 não são roteados pela Internet, então não vejo o que a tentativa de falsificá-los pela WAN fará. Eles nem dão o primeiro salto.
MDMarra 25/05

O endereço de destino é o endereço público do NAT na porta que é mapeada para o servidor. O endereço de origem é um dos endereços IP privados na parte interna do NAT. Os endereços de origem não são usados ​​no roteamento e não são verificados por todos os roteadores públicos. A única diferença de uma consulta interna legítima é que o pacote está vindo da WAN.
Kent England
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.