NAT de servidores públicos?

Question

Em suma, minha pergunta: "Qual é melhor? Atribuir endereços IP privados a servidores públicos e fazer NAT, ou atribuir endereços IP públicos a eles sem a necessidade de NAT"?

O NAT pode ser útil para os usuários permitirem que muitos usuários acessem a Internet usando um pequeno pool de endereços IP públicos (pode ser apenas um IP). Isso é chamado PATing também.

Estou discutindo NATing os endereços IP de servidores públicos, tais como: DNS, servidores Web, servidores de e-mail, etc NATing de servidores públicos deve ser feito usando NAT estático. Então, alguém pode pensar em eliminar o processo de NAT e atribuir os IPs públicos nos servidores. Aqui está uma comparação dos dois cenários.

Com o NAT:

+ Os endereços IP públicos são gerenciados e usados no gateway como desrired.

+ Os IPs públicos são preservados e podem ser usados da forma mais eficiente possível.

- Uma pequena sobrecarga será adicionada ao roteador / firewall do gateway.

- Os endereços IP privados podem ser expostos ao exterior (por exemplo, em cabeçalhos de e-mails ou em um erro de configuração).

- Precisamos criar duas visualizações para os servidores DNS (privados para usuários internos e públicos para usuários externos).

Sem NAT:

- Atribuir mais de um endereço IP para um servidor deve ser feito no próprio servidor. O aplicativo / serviço deve estar ciente de usar todos os IPs para o tráfego de saída.

- Os endereços IP públicos são atribuídos diretamente aos servidores. Assim, alguns IPs podem ser desperdiçados (não usados), como no caso de cluster e VIP.

+ O roteamento / encaminhamento será um pouco mais rápido, já que não estamos fazendo NAT (menos sobrecarga).

+ Todas as comunicações serão feitas usando os IPs públicos.

+ Uma exibição de DNS será suficiente, pois estamos usando os mesmos IPs internos e externos.

Quaisquer outras ideias / sugestões ??

    

Answer 1

Sou strongmente a favor da abordagem NAT. Como você diz, conserva o endereço IP público de forma mais eficaz e, além disso, você não expõe nenhum serviço ao mundo externo até que esteja intencionalmente pronto para isso - você pode atribuir um endereço público vinculado ao processo para aprovar um conjunto de regras de firewall. um determinado servidor.

Com o roteador Cisco que estamos usando, pelo menos, a sobrecarga do NAT é insignificante em comparação com a sobrecarga de usar o módulo de firewall , , e já que já estamos usando isso, o problema de desempenho não é um grande problema. Ele também possui uma regra de reescrita automática opcional para que os acessos aos endereços externos das redes internas sejam reescritos para o endereço interno por "mágica", evitando assim a necessidade de um DNS dividido. (Usamos um subdomínio .int para os endereços 10.x internos).

    

Answer 2

OK, isso foi perguntado há alguns dias e já existe uma resposta aceita.

Mantenha-se simples Senhor. De um modo geral, um servidor público da Internet deve ter um endereço IP público.

With NATing: The public IPs are preserved and can be used as efficiently as possible.

IMHO um pouco de vermelho. OK, é verdade, mas os v4 IP's não são tão escassos e, além disso, não é da sua inteira responsabilidade corrigir a "falta de endereço" na Internet.

Without NATing: Assigning more than one IP address for a server should be done on the server itself. The application/service should be aware to use all the IPs for the outgoing traffic.

Por que atribuir vários endereços IP? Se você tiver vários serviços, use CNAMES de DNS e intervalos de porta IP para dividir as coisas. Se você precisar conservar IPs ao fazer IPs flutuantes (VIPs), poderá usar IPs privados para o IP específico da máquina e apenas usar IPs públicos para o VIP real em que você publica aplicativos da Internet.

A meu ver, resume-se principalmente a:

• Com o NAT, você ganha um pouco de segurança através da obscuridade. Isso tem pouco valor.

• Sem o NAT, você segue as intenções de design da Internet. As ferramentas comuns de solução de problemas, como o Ping etc, funcionam conforme o esperado. Sysadmins em outros sites & ISPs upstream podem trabalhar melhor junto com você para corrigir problemas.

Minha clara preferência é um IP público por servidor, a menos que haja alguma restrição local que me obrigue a fazer o contrário.

    

Answer 3

@mattdm: Usar o NAT sem um firewall ao lado não é muito inteligente (também conhecido como "segurança" através da obscuridade).

Ao usar o NAT, você não precisa de uma visão interna do DNS se usar a NAT (ou NAT gancho).

Quanto à sua pergunta, eu diria que é uma questão de preferência.

• Você tem planos para os endereços IP que você salvaria?

• Você tem várias máquinas que fornecem os mesmos serviços que precisam ser acessados externamente usando as portas padrão?

• Qual a importância do seu roteador como gateway?

Eu diria que responder a essas perguntas ajudará você a determinar qual caminho seguir. Lembre-se de que, de qualquer forma, isso não importará muito e não impedirá que você use a outra estratégia posteriormente.

    

Answer 4

Eu tive problemas com o cenário "Sem Natting".

Seus clientes internos podem acabar tentando se conectar a servidores internos com seus IPs públicos. Isso pode fazer com que o tráfego seja roteado da rede interna para o roteador e, em seguida, de volta para a rede - ou pode falhar completamente, dependendo de como o roteamento está configurado.

Você precisa ter cuidado para que os clientes internos sempre obtenham o IP interno, caso contrário, você perderá o benefício "encaminhamento / encaminhamento será um pouco mais rápido".

EDITAR Eu posso ter explicado o acima mal. A lan interna tinha IPs privados. Ao decidir tornar alguns servidores voltados para o público, eles receberam IPs privados e públicos e o conjunto de roteadores / firewall para permitir o tráfego desses IPs públicos.

Os problemas ocorreram com clientes internos em IPs privados tentando acessar os servidores internos por meio de IPs públicos. Foi há vários anos e acho que o DNS e / ou roteamento foi mal configurado - por isso, para esta rede, os clientes internos começam a acessar um servidor em um IP interno.

Quando o primeiro servidor tentou direcionar o usuário para outro servidor, houve alguma confusão sobre os nomes / IPs internos / externos. Muitas vezes, o servidor apontava o cliente interno para um IP público e o cliente supunha que isso estava fora do roteador. O roteamento dos IPs privados para os IPs públicos não foi configurado corretamente e isso se mostrou inábil.

Como alternativa, o servidor apontaria o cliente para outro servidor pelo nome / IP interno e o cliente interno funcionaria bem, mas os clientes externos não funcionariam.

É possível ter essa configuração funcionando corretamente - mas é necessário pensar bem ou configurar a rede interna.

IIRC as questões foram resolvidas, garantindo que os servidores públicos tinham IP's privados não uma sub-rede interna separada para os clientes internos e garantindo que o roteamento no gateway padrão do cliente foi configurado corretamente.

Não estou dizendo que não faça isso, apenas adicionando algo que deve ser considerado.