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

Question

NAT-NAT loopback dentro-a-dentro resolve problemas de NAT hairpin ao acessar um servidor web na interface externa de um dispositivo ASA ou similar de computadores na interface interna. Isso impede que os administradores de DNS tenham que manter uma zona DNS interna duplicada que tenha os endereços RFC1918 correspondentes para seus servidores que estão NATted para endereços públicos. Eu não sou um engenheiro de rede, então eu posso estar faltando alguma coisa, mas isso parece ser um acéfalo para configurar e implementar. O roteamento assimétrico pode ser um problema, mas é facilmente mitigado.

Na minha experiência, administradores / engenheiros de rede preferem que os sistemas simplesmente executem o split-dns em vez de configurar seus firewalls para manipular corretamente os grampos de cabelo NAT. Por que isso acontece?

    

Answer 1

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

• Por que sobrecarregar os roteadores e firewall DMZ se você não precisa? A maioria 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. Fazendo dentro para dentro nat acrescenta mais carga para o DMZ, que no nosso caso seria significativo.
• Se você não fizer o DNAT + SNAT, receberá um roteamento assertivo, o que é notoriamente difícil de acertar. Então você SNAT e perder infomation IP de origem. No entanto, é muito útil vincular os 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 instável no serviço não autenticado X" "Ah, vamos ver nos logs do servidor imap quem é".

Answer 2

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

1. Elegância: NAT não é muito elegante para começar, mas uma necessidade com o espaço de endereçamento restrito do IPv4. Se eu puder evitar o NAT, eu irei. Com o IPv6, o problema está desaparecendo, de qualquer forma.
2. Complexidade: especialmente em um caso em que você não tem apenas um único roteador "central" que cria todos os limites de segurança, as configurações de filtro podem se tornar bastante complicadas. Ou você teria que espalhar e manter as regras de NAT em quase todos os seus dispositivos de roteador.
3. Referência: sempre que os administradores do firewall forem pessoas diferentes do restante da equipe de administração do servidor, poderão ser difíceis de alcançar. Para garantir que as alterações não sejam atrasadas pelo backlog (ou férias) do administrador do firewall, a opção de manter a responsabilidade na mesma equipe é escolhida
4. Portabilidade e prática comum: Usar exibições de DNS é "a única coisa que todo mundo sabe que é feito" para resolver esse problema. Nem todos os roteadores de limite suportariam NAT de loopback de forma direta, menos pessoas provavelmente saberão como configurá-lo corretamente em seu ambiente específico. Ao solucionar problemas de rede, a equipe precisaria estar ciente da configuração NAT do hairpin e de todas as suas implicações - mesmo quando estão perseguindo um problema aparentemente não relacionado

Answer 3

Aviso de isenção de responsabilidade - esta é uma resposta de flamebait.

Uma razão comum pela qual eu penso que soluções como essa são 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:

• link
• link (o blog de Tom parece continuar a atrair NATs fervorosos Discussão sobre IPv6)
• link (meu blog)

Pelo que eu posso dizer, muito deste medo deriva das implementações pobres da Cisco no NAT (então, nesse sentido, pode não ser irracional), mas, na minha opinião, o engenheiro de rede "clássico" é tão instruído quanto A visão de mundo "NAT é ruim", que ele não pode ver exemplos óbvios como esse, onde faz todo o sentido e simplifica a solução.

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

    

Answer 4

Meu palpite é:

1. O DNS dividido é mais facilmente entendido.
2. O NAT Hairpin 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 do split-dns.
4. O Split-dns sempre terá um desempenho melhor à medida que você evita as etapas de roteamento / NAT.

No lado positivo para NAT em gancho de cabelo,

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

Para uma pequena rede com baixos requisitos de tráfego para um servidor interno, eu usaria o hairpin NAT. Para uma rede maior com muitas conexões com o servidor e onde a largura de banda e a latência são importantes, vá com o split-dns.

    

Answer 5

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

No entanto, nem sempre precisamos manter uma zona DNS interna duplicada. O Cisco ASA pode redirecionar as consultas DNS para endereços externos para endereços internos, se configurado na instrução NAT. Mas eu prefiro manter uma zona interna para a zona pública do DNS, a fim de ter essa granularidade e ser capaz de gerenciá-lo em um único lugar, em vez de ir para o firewall.

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

    

Answer 6

Posso pensar em algumas razões:

1. Muitas organizações já dividiram o DNS como resultado de não querer publicar todas as suas informações de DNS interno para o 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. / li>
2. À medida que uma organização e sua rede se tornam maiores, elas geralmente separam os sistemas que atendem pessoas internas de servidores que prestam serviços externos, 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 pequeno, reconhecidamente) Existem protocolos que o NAT ainda quebrará se o dispositivo NAT não ultrapassar os cabeçalhos do pacote e modificar os dados nele com o (s) novo (s) endereço (s) IP. Mesmo que seja apenas um caso de memória institucional, ainda é uma razão válida para as pessoas evitá-lo, especialmente se estiverem lidando com um protocolo do qual não têm 100% de certeza.

Answer 7

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

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