Migração Enterprise IPv6 - Fim do proxypac? Início do ponto a ponto? + 10 mil usuários

Question

Vamos começar com um diagrama:

PodemosverumarededaempresaIPv4"típica" com:

• Acesso à Internet por meio de um proxy
• Acesso de "outras empresas" por meio de um proxy dedicado
• Um acesso direto aos recursos locais

Todos os computadores têm um arquivo proxy.pac que indica qual proxy usar ou se deve se conectar diretamente. Os computadores têm acesso apenas a um DNS local (sem resolução de nome para google.com, por exemplo).

A propósito ... A empresa não respeita a RFC1918 internamente e usa endereços públicos! (razão histórica). O uso do proxy da Internet permite explicitamente não ter problemas.

E se migrarmos para o IPv6?

Etapa 1: acesso à Internet IPv6

O acesso à Internet no IPv6 é fácil. Na verdade, basta conectar o proxy na Internet IPv4 e IPv6. Não há nada para fazer na rede interna:

Etapa 2: IPv6 E IPv4 na rede interna

E por que não rede IPv6 completa diretamente? Porque há sempre os servidores antigos que não são compatíveis IPv6 ..

Opção 1: mesma arquitetura do IPv4 com um proxy

Esta é provavelmente a solução mais fácil. Mas isso é o melhor?

Acho que a transição para o IPv6 é uma oportunidade de não se incomodar com esse pac proxy!

Opção 2: nova arquitetura com proxy transparente, sem proxypac, DNS recursivo

Ah sim!

Nesta nova arquitetura, temos:

• Explicit Internet Proxy se torna um Transparent Internet Proxy
• Local DNS torna-se um Normal Recursive DNS + authorative para domínios locais
• Sem proxypac
• Explicit Company Proxy se torna um Transparent Company Proxy
• Roteamento
  • Os roteadores internos redefinem o IP de appx.ext.example.com para Company Proxy .
  • O gateway padrão é o Transparent Internet proxy .

Perguntas

• O que você acha desta arquitetura IPv6?
• Essa arquitetura revelará os endereços IP de nossa rede interna, mas é protegida por firewalls. Isso é um grande problema? Devemos manter o uso explícito de um proxy? -Como você faria para este cenário de migração? -E você, como você faz na sua empresa?

Obrigado! Sinta-se à vontade para editar minha postagem para melhorar.

    

Answer 1

Proxies bem transparentes não funcionam para o tráfego SSL, a menos que você implemente uma raiz confiável alternativa para cada dispositivo, assim você perde muitos benefícios de segurança e auditoria e introduz novos benefícios.

Eu iria com a opção 2, mas usando um proxy explícito, desligue tudo. Se as máquinas internas não usarem seu proxy, elas não terão acesso à Internet. Você já deve ter ferramentas para distribuir automaticamente a configuração do proxy por meio de scripts, Políticas de Grupo do Windows, DHCP ou DNS / proxy.pac.

O mais simples geralmente é melhor.

    

Answer 2

Eu rebatei com outra pergunta. Por que você realmente precisa de proxy? Por causa da incompatibilidade RFC1918? Isso justifica totalmente o uso de proxy quando você escolhe não reconstruir sua arquitetura IPv4 para usar endereços 10.xxx (meu ISP costumava nos fornecer endereços não RFC1918, mas usava um NAT, agora temos 10.xxx e o NAT, é claro) . Ou você usa o proxy para caching / security / filtering / auditing?

Se a resposta à primeira pergunta for verdadeira, eu optaria por uma opção muito simples 1: colocar um roteador IPv6 muito simples na sua borda, atualizar seu (s) DHCP (s) para transmitir um prefixo IPv6 e fazer seu tráfego IPv6 através do seu roteador. Já que você já precisa atualizar seus roteadores do meio (aqueles que ficam entre os hosts do cliente e o roteador de borda) isso não adiciona um custo extra ao hardware.

Isso tem a vantagem de manter o IPv4 ativo e disponível para máquinas que não o suportam, que se comportarão como antes.

Para responder às suas perguntas: 1) sua escolha arquitetônica (na figura) não mostra suporte para IPv6 em máquinas clientes, o que é um desperdício real. 2) IPs "reveladores" são comuns em IPv6 porque não há NAT. Você só precisa de um pouco de cuidado extra com o firewall e os endereços de privacidade (conforme indicado na outra resposta) protegem a privacidade das máquinas clientes contra servidores fora do domínio.

    

Answer 3

Gostaria de manter o ip4 / ipv6, alguns dispositivos são bastante burros e não podem ser atualizados de qualquer maneira. Se você pode separar por vlans.

Em seguida, use explicitamente o proxy http. Não use proxy transparente. Por quê? Você pode facilmente detectar que há um aplicativo ou dispositivo mal configurado tentando acessar a Internet. Você deve distinguir entre tráfego "normal" e tráfego "estranho". As informações sobre o uso obrigatório de proxy HTTP devem fazer parte da educação dos funcionários.

Você pode configurar um proxy http que encaminhará domínios específicos para outro proxy pai (para os sites de seus clientes específicos). Isso resolve o problema do arquivo pac, você define nos aplicativos dos clientes apenas um proxy http.

Não ative dns recursivos em sua LAN! Trabalhos de tunelamento de DNS! Não habilite ping fora da LAN (tunelamento ICMP), não há necessidade de clientes! Habilite dns recursivos somente para o seu proxy http ou para os aplicativos que realmente precisam fazer consultas dns.

De acordo com uma análise, apenas 20% dos administradores de rede sabem o que está deixando a rede: D

Eu realmente gosto de dar aos clientes acesso http [s] via cliente remoto (RDP, Citrix ...), mas isso parece muito caro.

Esta é uma boa leitura - link

    

Answer 4

Uma outra coisa a considerar é uma abordagem em fases em que uma nova rede de hosts somente IPv6 acessa a LAN antiga via NAT64 / DNS64.

Parece provável que você queira rodar o dual-stack por um tempo. A mesma abordagem pode ser usada para corrigir a não-conformidade com a RFC1918, fazendo proxy / endereços NATing 10.x.x.x v4 para a LAN antiga. Supondo que seus IPs públicos sejam sequestrados. Se você obteve a alocação de IANA / ARIN / etc ... então não é um problema.