Voltar 
Coautoria de Jeff Brainard e Jason Hofmann
Em mais de uma conversa com clientes de grandes empresas, ouvimos líderes de rede e infraestrutura responsáveis por gerenciar a WAN global de uma organização brincando e referindo-se a si mesmos como “Chief Hairpinning Officer” ou CHO (algo como “Diretor de Grampos de Cabelo”). A primeiro momento, isso é engraçado. No entanto, há mais do que um pouco de verdade nesta afirmação se considerarmos quanto tempo, energia e orçamento os profissionais de redes têm gastado regularmente no gerenciamento de decisões complexas de roteamento. Essas decisões foram fundamentais para unir diferentes sites corporativos e filiais ao data center e, ao mesmo tempo, trabalhar com vários provedores de Internet, a fim de garantir acesso rápido e confiável para seus usuários, além de uma experiência responsiva com as aplicações. Mas a tarefa árdua dos últimos anos foi alinhar esses objetivos de redes com os crescentes requisitos de segurança que as empresas enfrentam. O problema só se agravou com a migração de aplicações e dados para a nuvem e para SaaS, com ataques cada vez mais complexos, combinados com a explosão mais recente no trabalho remoto.
What is hairpinning?
Most enterprises today leverage an architecture that relies heavily on “hairpinning” or what’s also commonly referred to as traffic backhauling. In a networking context, hairpinning refers to the way a packet travels to an interface, goes out towards the internet but instead of continuing on, makes a “hairpin turn”—just think of the everyday instrument used to hold a person’s hair in place—and comes back in on the same interface. The classic scenario is the branch office, where no traffic should enter or exit without first getting security checked. Deploying a standalone security stack at every branch, across dozens or even hundreds of branch locations around the world, could be a viable strategy but from a cost, complexity, and administrative burden perspective it would be a nightmare.
Em vez disso, a abordagem preferida tem sido desviar todas os requests de Internet das filiais (usando um “hairpinning”) para um local central, como o data center, onde está a aplicação de segurança, e só então, após ser verificado, enviar o tráfego para a internet. E isso acontece tanto ao fazer um request de conteúdo da web ou ao interagir com uma aplicação SaaS crítica para os negócios. Na resposta do servidor, o tráfego precisa seguir o mesmo caminho tortuoso de volta do data center à filial e, finalmente, ao desktop do usuário. Não é necessário ser um engenheiro de rede para perceber que essa abordagem afetará a experiência do usuário, adicionando latência e tornando as coisas significativamente mais lentas. Colocando de lado a experiência do usuário e, em última instância, a produtividade da empresa, essa abordagem também sobrecarrega links WAN privados que são caros e difíceis de manter, como as conexões MPLS, nas quais as empresas confiam há muito tempo para unir sua infraestrutura distribuída.
The evolution of hairpinning to WAN/SD-WAN
With the unarguable shift of applications and data to the cloud, and the growing volume and criticality of this traffic, one of the great attractions of the cloud security model is to eliminate hairpinning and dramatically simplify network design. It’s also one of the key drivers for the booming SD-WAN market and the impetus for large-scale network transformation projects. This was covered in another recent blog titled “How Netskope NewEdge Takes SD-WAN to the Next Level.” The conclusion one can draw is that networking professionals would prefer to avoid hairpinning and the future will increasingly be about sending their traffic direct-to-net with a cloud-first approach to security. So why then would a customer select a cloud security solution that relies on a hairpinning network architecture?
Infelizmente, uma das coisas que vimos repetidamente no mercado, e é comum com quase todos os fornecedores de segurança em nuvem, é que eles arquitetaram suas nuvens de maneira totalmente errada. Essencialmente, o que você descobre é que eles estão repetindo os erros inerentes ao design tradicional da WAN corporativa e replicando-os dentro do cloud form fator. Um exemplo disso é o ponto de presença virtual (ou vPOP), uma abordagem conhecida por ser usada por fornecedores como Broadcom / Symantec, Palo Alto, Forcepoint, McAfee e outros. Para verificar esta informação, confira o site dessas empresas e procure frases como "Localização física do cálculo de segurança" ou o termo "vPOP.") Os vPOPs não apenas fornecem uma visão enganosa da cobertura, mas também enganam sobre onde o processamento de tráfego ocorre dentro da rede do fornecedor de segurança na nuvem.
De forma mais simples, os vPOPs fornecem um ponto de entrada e saída para o tráfego. Um exemplo disso, discutido em um blog anterior chamado “Compreender a cobertura não se trata apenas de contar data centers,” apresentou um cenário com um suposto usuário remoto no Quênia. Esse usuário precisaria se conectar a um vPOP em Joanesburgo, na África do Sul, ter seu tráfego enviado para processamento em Frankfurt, na Alemanha, e em seguida, ser mandado de volta para Joanesburgo – isso antes que a solicitação do usuário fosse para a Internet e para a web, nuvem ou para a aplicação SaaS que ele estava tentando acessar. Imagine a latência introduzida com esse vai e vem de tráfego, roteando por grandes distâncias, por várias redes, em última instância, retardando a experiência do usuário até ela virar um “rastejar.” O segredo é que os vPOPs são literalmente redutores de tráfego com as mesmas implicações na complexidade, latência e custo em potencial.
Além disso, quando os fornecedores dependem da infraestrutura de uma nuvem pública, como AWS, Azure ou GCP, eles contam com os data centers de borda desses provedores para fornecer pontos de saída regionais para o tráfego (Palo Alto). Ou pior ainda, e muito mais comum: eles fazem backhaul sobre a congestionada e imprevisível Internet pública e usam um "banco telefônico" de IPs de saída, cada um registrado em um país diferente, para implementar seus vPOPs. O mesmo problema acontece novamente, com o tráfego tendo que ser direcionado por grandes distâncias, desviado para vários locais antes de eventualmente chegar aos poucos—muitas vezes menos de 30—locais únicos no mundo onde os recursos de computação estão localizados e onde o processamento de segurança no tráfego pode ocorrer. Os clientes pensam que estão comprando uma estratégia de nuvem para ir direto para a rede, com as proteções críticas de segurança de que precisam, mas o que estão obtendo na verdade são os mesmos problemas de rede do passado reimplementados dentro da nuvem. Este é o segredo oculto da maioria dos fornecedores de segurança em nuvem.
The power of NewEdge
Outro exemplo de pesadelo na rede de um conhecido fornecedor de segurança na nuvem apareceu recentemente com um cliente com quem estávamos trabalhando na América Latina. Embora o fornecedor anunciasse quatro data cente