Introdução à rede robusta do Azure Stack Hub

Visão geral do design de rede

Design de rede física

A solução robusta do Azure Stack Hub requer uma infraestrutura física resiliente e altamente disponível para dar suporte a sua operação e serviços. Os uplinks dos comutadores ToR para Border são limitados à mídia SFP+ ou SFP28 e a velocidades de 1 GB, 10 GB ou 25 GB. Verifique com o fornecedor de hardware OEM (fabricante de equipamento original) para obter disponibilidade.

O diagrama a seguir apresenta nosso design recomendado para o Azure Stack Hub robusto.

Rede física robusta do Azure Stack Hub

Design de rede lógica

Um design de rede lógica representa uma abstração de uma infraestrutura de rede física. Eles são usados para organizar e simplificar as atribuições de rede para hosts, VMs (máquinas virtuais) e serviços. Como parte da criação de rede lógica, os sites de rede são criados para definir:

  • VLANs (redes locais virtuais)
  • Sub-redes IP
  • Pares de sub-rede/VLAN de IP

Todos os quais estão associados à rede lógica em cada local físico.

A tabela a seguir mostra as redes lógicas e os intervalos de sub-rede IPv4 associados para os quais você deve planejar:

Rede lógica Descrição Tamanho
IP virtual público (VIP) O Azure Stack Hub robusto usa um total de 31 endereços dessa rede. Oito endereços IP públicos são usados para um pequeno conjunto de serviços robustos do Azure Stack Hub e o restante é usado por VMs de locatário. Se você planeja usar Serviço de Aplicativo e os provedores de recursos do SQL, mais 7 endereços serão usados. Os 15 IPs restantes são reservados para futuros serviços do Azure. /26 (62 hosts)-
/22 (1022 hosts)

Recomendado = /24 (254 hosts)
Alternar infraestrutura Endereços IP ponto a ponto para fins de roteamento, interfaces de gerenciamento de comutador dedicadas e endereços de loopback atribuídos à opção. / 26
Infraestrutura Usado para que os componentes internos robustos do Azure Stack Hub se comuniquem. /24
Privado Usado para a rede de armazenamento, VIPs privados, contêineres de infraestrutura e outras funções internas. /20
Controlador de Gerenciamento de Placa-base (BMC) Usado para se comunicar com os controladores de gerenciamento do quadro de base nos hosts físicos. / 26

Infraestrutura de rede

A infraestrutura de rede do Azure Stack Hub robusto consiste em várias redes lógicas configuradas nos comutadores. O diagrama a seguir mostra essas redes lógicas e como elas se integram aos comutadores TOR (top-of-rack), controlador de gerenciamento de placa base e borda (rede do cliente).

Diagrama de rede lógica robusta do Azure Stack Hub:

Rede lógica robusta do Azure Stack Hub

Rede BMC

Essa rede é dedicada a conectar todos os controladores de gerenciamento de placa base (também conhecidos como BMC ou processadores de serviço) à rede de gerenciamento. Os exemplos incluem: iDRAC, iLO, iBMC e assim por diante. Apenas uma conta do BMC é usada para se comunicar com qualquer nó BMC. Se presente, o HLH (Host do Ciclo de Vida de Hardware) está localizado nessa rede e pode fornecer software específico do OEM para manutenção ou monitoramento de hardware.

O HLH também hospeda a DVM (VM de Implantação). O DVM é usado durante a implantação robusta do Azure Stack Hub e é removido quando a implantação é concluída. O DVM requer acesso à Internet em cenários de implantação conectados para testar, validar e acessar vários componentes. Esses componentes podem estar dentro e fora da rede corporativa (por exemplo: NTP, DNS e Azure). Para obter mais informações sobre os requisitos de conectividade, consulte a seção NAT na integração de firewall robusto do Azure Stack Hub.

Rede privada

A rede /20 (IPs de host 4096) é privada para a região robusta do Azure Stack Hub. Ele não se expande além dos dispositivos comutador de borda da região robusta do Azure Stack Hub. Essa rede é dividida em várias sub-redes, por exemplo:

  • Rede de armazenamento: uma rede /25 (128 IPs) usada para dar suporte ao uso do tráfego de armazenamento SMB (Bloco de Mensagens diretas e de servidor) do Spaces e da migração dinâmica da VM.
  • Rede IP virtual interna: uma rede /25 dedicada a VIPs somente internos para o balanceador de carga de software.
  • Rede de contêineres: uma rede /23 (512 IPs) dedicada ao tráfego somente interno entre contêineres que executam serviços de infraestrutura

O tamanho da Rede Privada é /20 (4096 IPs) de espaço ip privado. Essa rede é privada para o sistema robusto do Azure Stack Hub. Ele não roteia além dos dispositivos comutador de borda do sistema robusto do Azure Stack Hub e pode ser reutilizado em vários sistemas robustos do Azure Stack Hub. Embora a rede seja privada para o Azure Stack Hub robusto, ela não deve se sobrepor a outras redes no datacenter. Para obter diretrizes sobre o espaço ip privado, recomendamos seguir o RFC 1918.

O espaço de IP privado /20 é dividido em várias redes, que permitem que a infraestrutura do sistema robusto do Azure Stack Hub seja executada em contêineres em versões futuras. Consulte as notas de versão de 1910 para obter detalhes. Esse novo espaço ip privado permite esforços contínuos para reduzir o espaço de IP roteável necessário antes da implantação.

Rede de infraestrutura robusta do Azure Stack Hub

A rede /24 é dedicada a componentes robustos internos do Azure Stack Hub, para comunicar e trocar dados entre si. Essa sub-rede pode ser roteável externamente da solução robusta do Azure Stack Hub para seu datacenter. Não recomendamos usar endereços IP roteáveis públicos ou da Internet nesta sub-rede. Essa rede é anunciada para a Borda, mas a maioria de seus IPs são protegidos por ACLs (Listas de Controle de Acesso). Os IPs permitidos para acesso estão dentro de um intervalo pequeno, equivalente em tamanho a uma rede /27. Os serviços de host de IPs, como o PEP (ponto de extremidade privilegiado) e o Backup robusto do Azure Stack Hub.

Rede VIP pública

A Rede VIP Pública é atribuída ao controlador de rede no Azure Stack Hub robusto. Não é uma rede lógica no comutador. O SLB usa o pool de endereços e atribui redes /32 para cargas de trabalho de locatário. Na tabela de roteamento de comutador, esses IPs /32 são anunciados como uma rota disponível por meio do BGP (Border Gateway Protocol). Essa rede contém endereços públicos acessíveis externamente. A infraestrutura robusta do Azure Stack Hub reserva os primeiros 31 endereços dessa Rede VIP Pública, enquanto o restante é usado por VMs de locatário. O tamanho da rede nessa sub-rede pode variar de um mínimo de /26 (64 hosts) a um máximo de /22 (1022 hosts). Recomendamos que você planeje uma rede /24.

Alternar rede de infraestrutura

A rede /26 é a sub-rede que contém as sub-redes IP /30 (dois IPs de host) roteáveis e os loopbacks. São sub-redes /32 dedicadas para gerenciamento de comutador em banda e ID do roteador BGP. Esse intervalo de endereços IP deve ser roteável fora da solução robusta do Azure Stack Hub para o datacenter. Os endereços IP podem ser privados ou públicos.

Alternar rede de gerenciamento

A rede /29 (seis IPs de host) é dedicada a conectar as portas de gerenciamento dos comutadores. Essa rede permite acesso fora de banda para implantação, gerenciamento e solução de problemas. Ele é calculado a partir da rede de infraestrutura de comutador mencionada acima.

Visão geral do design DNS

Para acessar pontos de extremidade robustos do Azure Stack Hub (portal, adminportal,gerenciamento, administrador) de fora do Azure Stack Hub robusto, você deve integrar os serviços DNS robustos do Azure Stack Hub aos servidores DNS que hospedam as zonas DNS que você deseja usar no Azure Stack Hub robusto.

Namespace DNS robusto do Azure Stack Hub

Você precisa fornecer algumas informações importantes relacionadas ao DNS ao implantar o Azure Stack Hub robusto.

Campo Descrição Exemplo
Região A localização geográfica da implantação robusta do Azure Stack Hub. leste
Nome de Domínio Externo O nome da zona que você deseja usar para sua implantação robusta do Azure Stack Hub. cloud.fabrikam.com
Nome do Domínio Interno O nome da zona interna usada para serviços de infraestrutura no Azure Stack Hub robusto. Ele é integrado ao serviço de diretório e privado (não acessível de fora da implantação robusta do Azure Stack Hub). azurestack.local
Encaminhadores DNS Servidores DNS que são usados para encaminhar consultas DNS, zonas DNS e registros hospedados fora do Azure Stack Hub robustos, seja na intranet corporativa ou na Internet pública. Você pode editar o valor do Encaminhador DNS com o cmdlet Set-AzSDnsForwarder após a implantação.
Prefixo de Nomenclatura (opcional) O prefixo de nomenclatura que você deseja que seus nomes de computador de instância de função de infraestrutura robustos do Azure Stack Hub tenham. Se não for fornecido, o padrão será "azs". Azs

O FQDN (nome de domínio totalmente qualificado) da implantação e dos pontos de extremidade robustos do Azure Stack Hub é a combinação do parâmetro Region e do parâmetro Nome de Domínio Externo. Usando os valores dos exemplos na tabela anterior, o FQDN para essa implantação robusta do Azure Stack Hub seria: east.cloud.fabrikam.com

Assim, os exemplos de alguns dos pontos de extremidade dessa implantação seriam parecidos com as seguintes URLs:

  • https://portal.east.cloud.fabrikam.com
  • https://adminportal.east.cloud.fabrikam.com

Para usar este namespace DNS de exemplo para uma implantação robusta do Azure Stack Hub, as seguintes condições são necessárias:

  • O fabrikam.com de zona é registrado com um registrador de domínio, servidor DNS corporativo interno ou ambos. O registro depende dos requisitos de resolução de nomes.
  • O domínio filho cloud.fabrikam.com existe na zona fabrikam.com.
  • Os servidores DNS que hospedam as zonas fabrikam.com e cloud.fabrikam.com podem ser acessados por meio da implantação robusta do Azure Stack Hub.

Para resolve nomes DNS para pontos de extremidade robustos do Azure Stack Hub e instâncias de fora do Azure Stack Hub robustos, você deve integrar os servidores DNS. Incluindo servidores que hospedam a zona DNS externa para o Azure Stack Hub robusto, com os servidores DNS que hospedam a zona pai que você deseja usar.

Rótulo de nome DNS

O Azure Stack Hub robusto dá suporte à adição de um rótulo de nome DNS a um endereço IP público para permitir a resolução de nomes para endereços IP públicos. Os rótulos DNS são uma maneira conveniente para os usuários acessarem aplicativos e serviços hospedados no Azure Stack Hub robustos por nome. O rótulo de nome DNS usa um namespace ligeiramente diferente dos pontos de extremidade de infraestrutura. Seguindo o namespace de exemplo anterior, o namespace para rótulos de nome DNS seria: *.east.cloudapp.cloud.fabrikam.com.

Se um locatário especificar Myapp no campo nome DNS de um recurso de endereço IP público, ele criará um registro A para myapp na zona east.cloudapp.cloud.fabrikam.com no servidor DNS externo robusto do Azure Stack Hub. O nome de domínio totalmente qualificado resultante seria: myapp.east.cloudapp.cloud.fabrikam.com.

Se você quiser aproveitar essa funcionalidade e usar esse namespace, deverá integrar os servidores DNS. Incluindo servidores que hospedam a zona DNS externa para o Azure Stack Hub robusto e os servidores DNS que hospedam a zona pai que você deseja usar também. Esse namespace é diferente do usado para os pontos de extremidade de serviço robustos do Azure Stack Hub, portanto, você deve criar uma delegação adicional ou regra de encaminhamento condicional.

Para obter mais informações sobre como o rótulo de Nome DNS funciona, consulte "Usando DNS" no Azure Stack Hub robusto.

Resolução e delegação

Existem dois tipos de servidores DNS:

  • Um servidor DNS autoritativo hospeda zonas DNS. Ele responde a consultas DNS apenas para registros nessas zonas.
  • Um servidor DNS recursivo não hospeda zonas DNS. Ele responde a todas as consultas DNS chamando os servidores DNS autoritativos para coletar os dados de que precisa.

O Azure Stack Hub robusto inclui servidores DNS autoritativos e recursivos. Os servidores recursivos são usados para resolve nomes de tudo, exceto a zona privada interna e a zona DNS pública externa para a implantação robusta do Azure Stack Hub.

Resolvendo nomes DNS externos do Azure Stack Hub robusto

Para resolve nomes DNS para pontos de extremidade fora do Azure Stack Hub robustos (por exemplo: www.bing.com), você deve fornecer servidores DNS para o Azure Stack Hub robustos para encaminhar solicitações DNS, para as quais o Azure Stack Hub robusto não é autoritativo. Os servidores DNS aos quais o Azure Stack Hub foi robusto encaminha solicitações são necessários na Planilha de Implantação (no campo Encaminhador DNS). Forneça pelo menos dois servidores nesse campo para tolerância a falhas. Sem esses valores, a implantação robusta do Azure Stack Hub falha. Você pode editar os valores do Encaminhador DNS com o cmdlet Set-AzSDnsForwarder após a implantação.

Visão geral do design do firewall

É recomendável que você use um dispositivo de firewall para ajudar a proteger o Azure Stack Hub robusto. Os firewalls podem ajudar na defesa contra ataques de DDOS (negação de serviço distribuído), detecção de intrusão, inspeção de conteúdo e outros. No entanto, eles também podem afunilar a taxa de transferência de serviços de armazenamento do Azure, como blobs, tabelas e filas.

Se um modo de implantação desconectado for usado, você deverá publicar o ponto de extremidade AD FS. Para obter mais informações, consulte o artigo identidade de integração do datacenter.

Os pontos de extremidade do Azure Resource Manager (administrador), o portal do administrador e o Key Vault (administrador) não exigem necessariamente a publicação externa. Por exemplo, como um provedor de serviços, você pode limitar a superfície de ataque administrando apenas o Azure Stack Hub robusto de dentro de sua rede e não da Internet.

Para empresas, a rede externa pode ser a rede corporativa existente. Nesse cenário, você deve publicar pontos de extremidade para operar o Azure Stack Hub robusto da rede corporativa.

Conversão de endereços de rede

A NAT (Conversão de Endereços de Rede) é o método recomendado para permitir que a DVM (máquina virtual) de implantação acesse recursos externos durante a implantação. Também para as VMs do ERCS (Console de Recuperação de Emergência) ou PEP (ponto de extremidade privilegiado) durante o registro e a solução de problemas.

O NAT também pode ser uma alternativa para endereços IP públicos na rede externa ou VIPs públicos. No entanto, ele não é recomendável porque limita a experiência do usuário do locatário e aumenta a complexidade. Uma opção seria um NAT de um para um que ainda exija um IP público por IP de usuário no pool. Outra opção é um NAT de muitos para um que exija uma regra NAT por VIP de usuário para todas as portas que um usuário possa usar.

Algumas das desvantagens de usar NAT para VIP Público são:

  • Sobrecarga ao gerenciar regras de firewall, pois os usuários controlam seus próprios pontos de extremidade e regras de publicação na pilha SDN (rede definida pelo software). Os usuários devem entrar em contato com o operador robusto do Azure Stack Hub para publicar seus VIPs e atualizar a lista de portas.
  • Embora o uso de NAT limite a experiência do usuário, ele proporciona controle total ao operador sobre as solicitações de publicação.
  • Em cenários de nuvem híbrida com o Azure, considere que o Azure não dá suporte à configuração de um túnel de VPN para um ponto de extremidade usando NAT.

Interceptação de SSL

Atualmente, é recomendável desabilitar qualquer interceptação SSL (por exemplo, descarregamento de descriptografia) em todo o tráfego robusto do Azure Stack Hub. Se houver suporte em atualizações futuras, serão fornecidas diretrizes sobre como habilitar a interceptação SSL para o Azure Stack Hub robusto.

Cenário de firewall de implantação do Edge

Em uma implantação de borda, o Azure Stack Hub robusto é implantado diretamente atrás do roteador de borda ou do firewall. Nesses cenários, há suporte para que o firewall esteja acima da borda (Cenário 1) em que dá suporte a configurações de firewall ativo-ativo e ativo-passivo. Ele também pode atuar como o dispositivo de borda (Cenário 2), no qual ele dá suporte apenas à configuração de firewall ativo-ativo. O cenário 2 depende do ECMP (multi-caminho de custo igual) com o BGP ou o roteamento estático para failover.

Os endereços IP roteáveis públicos são especificados para o pool VIP público da rede externa, no momento da implantação. Para fins de segurança, IPs roteáveis públicos não são recomendados em nenhuma outra rede em um cenário de borda. Esse cenário permite que um usuário tenha toda a experiência em nuvem totalmente controlada como em uma nuvem pública similar ao Azure.

Cenário de firewall de borda robusto do Azure Stack Hub

Cenário de firewall de rede ou de perímetro ou intranet empresarial

Em uma intranet corporativa ou implantação de perímetro, o Azure Stack Hub robusto é implantado em um firewall de várias zonas ou entre o firewall de borda e o firewall de rede corporativa interno. Em seguida, seu tráfego é distribuído entre a rede de perímetro segura (ou a DMZ) e as zonas não seguras, como descrito abaixo:

  • Zona segura: a rede interna que usa endereços IP roteáveis internos ou corporativos. A rede segura pode ser dividida. Ele pode ter acesso de saída à Internet por meio da NAT do Firewall. Normalmente, ele é acessível de dentro do datacenter por meio da rede interna. Todas as redes robustas do Azure Stack Hub devem residir na zona segura, exceto no pool vip público da rede externa.
  • Zona do perímetro. A rede de perímetro é onde aplicativos externos ou voltados para a Internet, como servidores Web, normalmente são implantados. Normalmente, ele é monitorado por um firewall para evitar ataques como DDoS e intrusão (hacking) enquanto ainda permite o tráfego de entrada especificado da Internet. Somente o pool VIP público de rede externa do Azure Stack Hub robusto deve residir na zona DMZ.
  • Zona não segura. A rede externa, a Internet. Não é recomendável implantar o Azure Stack Hub robusto na zona não seguro.

Cenário de firewall de rede de perímetro

Visão geral do design de VPN

Embora a VPN seja um conceito de usuário, há algumas considerações importantes que um proprietário e operador de solução precisam saber.

Antes de enviar o tráfego de rede entre sua rede virtual do Azure e seu site local, você deve criar um gateway de VPN (rede virtual) para sua rede virtual.

Um gateway de VPN é um tipo de gateway de rede virtual que envia o tráfego criptografado em uma conexão pública. Você pode usar gateways de VPN para enviar tráfego com segurança entre uma rede virtual no Azure Stack Hub robusta e uma rede virtual no Azure. Você também pode enviar tráfego com segurança entre uma rede virtual e outra rede conectada a um dispositivo VPN.

Ao criar um gateway de rede virtual, especifique o tipo de gateway que você deseja criar. O Azure Stack Hub robusto dá suporte a um tipo de gateway de rede virtual: o tipo vpn .

Cada rede virtual pode ter dois gateways de rede virtual, mas somente um de cada tipo. Dependendo das configurações que você escolher, é possível criar várias conexões a um único gateway de VPN. Um exemplo desse tipo de configuração é uma configuração de conexão de vários sites.

Antes de criar e configurar gateways de VPN para o Azure Stack Hub robusto, examine as considerações sobre a rede robusta do Azure Stack Hub. Você aprenderá como as configurações do Azure Stack Hub robusto diferem do Azure.

No Azure, a taxa de transferência de largura de banda para a SKU do gateway de VPN escolhida deve ser dividida entre todas as conexões conectadas ao gateway. No entanto, no Azure Stack Hub robusto, o valor de largura de banda para o SKU do gateway de VPN é aplicado a cada recurso de conexão conectado ao gateway. Por exemplo:

  • No Azure, o SKU de gateway de VPN básico pode acomodar aproximadamente 100 Mbps de taxa de transferência agregada. Se você criar duas conexões com esse gateway de VPN e uma conexão estiver usando 50 Mbps de largura de banda, 50 Mbps ficarão disponíveis para a outra conexão.
  • No Azure Stack Hub robusto, cada conexão com o SKU básico do gateway de VPN é alocada 100 Mbps de taxa de transferência.

Tipos de VPN

Quando você cria o gateway de rede virtual para uma configuração de gateway de VPN, é preciso especificar um tipo de VPN. O tipo de VPN que você escolhe depende da topologia de conexão que quer criar. Um tipo de VPN também pode depender do hardware que você usa. As configurações S2S requerem um dispositivo VPN. Alguns dispositivos VPN recebem suporte apenas de um determinado tipo de VPN.

Importante

Atualmente, o Azure Stack Hub robusto dá suporte apenas ao tipo de VPN baseado em rota. Se o dispositivo der suporte apenas a VPNs baseadas em política, não há suporte para conexões com esses dispositivos do Azure Stack Hub robustos. Além disso, o Azure Stack Hub robusto não dá suporte ao uso de seletores de tráfego baseados em política para gateways baseados em rota no momento, pois não há suporte para configurações de política ipsec/IKE personalizadas.

  • PolicyBased: VPNs baseadas em política criptografam e direcionam pacotes por meio de túneis IPsec, com base em políticas IPsec. As políticas são configuradas com as combinações de prefixos de endereço entre a rede local e a VNet robusta do Azure Stack Hub. A política, ou seletor de tráfego, geralmente é uma lista de acesso na configuração do dispositivo VPN. O PolicyBased tem suporte no Azure, mas não no Azure Stack Hub robusto.
  • RouteBased: as VPNs baseadas em rota usam rotas configuradas na tabela de encaminhamento ou roteamento de IP. As rotas direcionam pacotes para suas interfaces de túnel correspondentes. As interfaces de túnel criptografam ou descriptografam então os pacotes para dentro e para fora dos túneis. A política ou o seletor de tráfego para VPNs RouteBased são configurados como qualquer para qualquer (ou usam curingas). Por padrão, eles não podem ser alterados. O valor de um tipo de VPN RouteBased é RouteBased.

Configurando um gateway de VPN

Uma conexão de gateway de VPN depende de vários recursos que são configurados com configurações específicas. A maioria desses recursos pode ser configurada separadamente, mas em alguns casos eles devem ser configurados em uma ordem específica.

Configurações

As configurações escolhidas para cada recurso são essenciais para criar uma conexão bem-sucedida.

Este artigo ajuda você a entender:

  • Tipos de gateway, tipos de VPN e tipos de conexão.
  • Sub-redes de gateway, gateways de rede locais e outras configurações de recurso que talvez você queira considerar.

Diagramas de topologia de conexão

Há configurações diferentes disponíveis para conexões de gateway de VPN. Determine qual configuração melhor atende às suas necessidades. Nas seções a seguir, você pode exibir informações e diagramas de topologia sobre as seguintes conexões de gateway de VPN:

  • Modelo de implantação disponível
  • Ferramentas de configuração disponíveis
  • Links que levam você diretamente a um artigo, se disponível

Os diagramas e descrições nas seções a seguir podem ajudá-lo a selecionar uma topologia de conexão para corresponder aos seus requisitos. Os diagramas mostram as topologias de linha de base main, mas é possível criar configurações mais complexas usando os diagramas como guia.

Site a site e vários sites (túnel VPN IPsec/IKE)

Site a site

Uma conexão de gateway de VPN site a site (S2S) é uma conexão por túnel VPN IPsec/IKE (IKEv2). Esse tipo de conexão requer um dispositivo VPN localizado localmente e recebe um endereço IP público. Este dispositivo não pode ser localizado atrás de um NAT. As conexões S2S podem ser usadas para configurações entre instalações e híbridas.

Vários sites

Uma conexão de vários sites é uma variação da conexão site a site. Você pode criar mais de uma conexão de VPN em seu gateway de rede virtual, normalmente se conectando a vários sites locais. Ao trabalhar com várias conexões, você deve usar um tipo de VPN baseado em rota (conhecido como gateway dinâmico ao trabalhar com VNets clássicas). Como cada rede virtual pode ter apenas um gateway de VPN, todas as conexões por meio do gateway compartilham a largura de banda disponível.

SKUs de gateway

Ao criar um gateway de rede virtual para o Azure Stack Hub robusto, especifique a SKU do gateway que deseja usar. Há suporte para os seguintes SKUs de gateway de VPN:

  • Basic
  • Standard
  • Alto Desempenho

Selecionar um SKU de gateway mais alto aloca mais CPUs e largura de banda de rede para o gateway. Como resultado, o gateway pode dar suporte a maior taxa de transferência de rede para a rede virtual.

O Azure Stack Hub robusto não dá suporte ao SKU de gateway de Desempenho Ultra, que é usado exclusivamente com o Express Route.

Considere o seguinte ao selecionar o SKU:

  • O Azure Stack Hub robusto não dá suporte a gateways baseados em política.
  • Não há suporte para BGP no SKU Básico.
  • Não há suporte para configurações de coexistência de gateway do ExpressRoute-VPN no Azure Stack Hub.

Disponibilidade do gateway

Cenários de alta disponibilidade só podem ser configurados na SKU de conexão do Gateway de Alto Desempenho . Ao contrário do Azure, que fornece disponibilidade por meio de configurações ativas/ativas e ativas/passivas, o Azure Stack Hub robusto dá suporte apenas à configuração ativa/passiva.

Failover

Há três VMs de infraestrutura de gateway multilocatário no Azure Stack Hub robustas. Duas dessas VMs estão no modo ativo e a terceira está no modo redundante. As VMs ativas permitem a criação de conexões VPN nelas e a VM redundante só aceita conexões VPN se ocorrer um failover. Se uma VM de gateway ativa ficar indisponível, a conexão VPN fará failover para a VM redundante após um curto período (alguns segundos) de perda de conexão.

Taxa de transferência agregada estimada por SKU

A tabela a seguir mostra os tipos de gateway e a taxa de transferência de agregação estimada por SKU de gateway:

Taxa de transferência de Gateway de VPN (1) Túneis IPsec máximo de Gateway de VPN (2)
SKU básico(3) 100 Mbps 20
SKU Standard 100 Mbps 20
SKU de alto desempenho 200 Mbps 10

Anotações da tabela

(1) – A taxa de transferência de VPN não é uma taxa de transferência garantida para conexões entre locais na Internet. É a medida de taxa de transferência máxima possível.
(2) – O máximo de túneis é o total por implantação robusta do Azure Stack Hub para todas as assinaturas.
(3) – O roteamento BGP não tem suporte para o SKU Básico.

Importante

Somente uma conexão VPN site a site pode ser criada entre duas implantações robustas do Azure Stack Hub. Isso ocorre devido a uma limitação na plataforma que permite apenas uma única conexão VPN com o mesmo endereço IP. Como o Azure Stack Hub robusto aproveita o gateway multilocatário, que usa um único IP público para todos os gateways de VPN no sistema robusto do Azure Stack Hub, pode haver apenas uma conexão VPN entre dois sistemas robustos do Azure Stack Hub.

Essa limitação também se aplica à conexão de mais de uma conexão VPN site a site a qualquer gateway de VPN que use um único endereço IP. O Azure Stack Hub robusto não permite que mais de um recurso de gateway de rede local seja criado usando o mesmo endereço IP.**

Parâmetros de IPsec/IKE

Ao configurar uma conexão VPN no Azure Stack Hub robusto, você deve configurar a conexão em ambas as extremidades. Se você estiver configurando uma conexão VPN entre o Azure Stack Hub robusto e um dispositivo de hardware, esse dispositivo poderá solicitar configurações adicionais. Por exemplo, um comutador ou roteador que está atuando como um gateway de VPN.

Ao contrário do Azure, que dá suporte a várias ofertas como iniciador e respondente, o Azure Stack Hub robusto dá suporte a apenas uma oferta por padrão. Se você precisar usar diferentes configurações de IPSec/IKE para trabalhar com seu dispositivo VPN, há mais configurações disponíveis para definir sua conexão manualmente.

Parâmetros da Fase 1 de IKE (Modo Principal)

Propriedade Valor
Versão IKE IKEv2
Grupo Diffie-Hellman ECP384
Método de autenticação Chave Pré-Compartilhada
Criptografia e algoritmos de hash AES256, SHA384
Tempo de vida da SA (Tempo) 28.800 segundos

Parâmetros da Fase 2 de IKE (Modo Rápido)

Propriedade Valor
Versão IKE IKEv2
Algoritmos de hash de & de criptografia (criptografia) GCMAES256
Algoritmos de hash de & de criptografia (autenticação) GCMAES256
Tempo de vida da SA (Tempo) 27.000 segundos
Tempo de vida de SA (Kilobytes) 33,553,408
PFS (Perfect Forward Secrecy) ECP384
Detecção de par inativo Com suporte

Configurar políticas de conexão IPSec/IKE personalizadas

O padrão de protocolo IKE e IPsec dá suporte a uma ampla gama de algoritmos criptográficos em várias combinações. Para ver quais parâmetros têm suporte no Azure Stack Hub robustos para atender aos requisitos de conformidade ou segurança, confira Parâmetros IPsec/IKE.

Este artigo fornece instruções sobre como criar e configurar uma política IPsec/IKE e aplicar a uma conexão nova ou existente.

Considerações

Observe as seguintes considerações importantes ao usar essas políticas:

  • A política IPsec/IKE só funciona nas SKUs de gateway Standard e HighPerformance (baseadas em rota).
  • Você só pode especificar uma combinação de políticas para uma determinada conexão.
  • Você deve especificar todos os algoritmos e parâmetros para IKE (modo principal) e IPsec (modo rápido). A especificação de política parcial não é permitida.
  • Consulte as especificações do fornecedor do dispositivo VPN para garantir que a política tem suporte em seus dispositivos VPN local. As conexões site a site não poderão ser estabelecidas se as políticas forem incompatíveis.

Fluxo de trabalho para criar e definir a política IPsec/IKE

Esta seção descreve o fluxo de trabalho necessário para criar e atualizar a política IPsec/IKE em uma conexão VPN site a site:

  1. Crie uma rede virtual e um gateway de VPN.
  2. Crie um gateway de rede local para conexão entre locais.
  3. Criar uma política de IPsec/IKE com parâmetros e algoritmos selecionados.
  4. Crie uma conexão IPSec com a política IPsec/IKE.
  5. Adicionar/atualizar/remover uma política de IPsec/IKE para uma conexão existente.

Algoritmos criptográficos e pontos fortes de chave com suporte

A tabela a seguir lista os algoritmos criptográficos com suporte e os pontos fortes de chave configuráveis pelos clientes robustos do Azure Stack Hub:

IPsec/IKEv2 Opções
Criptografia IKEv2 AES256, AES192, AES128, DES3, DES
Integridade do IKEv2 SHA384, SHA256, SHA1, MD5
Grupo DH ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None
Criptografia IPsec GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, nenhum
Integridade do IPsec GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupo PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, nenhum
Tempo de vida da QM SA (Opcional: os valores padrão serão usados se não for especificados)
Segundos (inteiro; min. 300/padrão 27.000 segundos)
KBytes (inteiro; min. 1024/default 102.400.000 KBytes)
Seletor de tráfego Não há suporte para seletores de tráfego baseados em política no Azure Stack Hub robusto.

A configuração do dispositivo VPN local deve corresponder ou conter os seguintes algoritmos e parâmetros que você especifica na política de IPsec/IKE do Azure:

  • Algoritmo de criptografia IKE (Modo Principal/Fase 1).
  • Algoritmo de integridade IKE (Modo Principal/Fase 1).
  • Grupo DH (Modo Principal/Fase 1).
  • Algoritmo de criptografia IPsec (Modo Rápido/Fase 2).
  • Algoritmo de integridade IPsec (Modo Rápido/Fase 2).
  • Grupo PFS (Modo Rápido/Fase 2).
  • Os tempos de vida de SA são apenas especificações locais, eles não precisam corresponder.

Se GCMAES for usado como para o algoritmo de Criptografia IPsec, você deverá selecionar o mesmo algoritmo GCMAES e o comprimento da chave para integridade IPsec. Por exemplo: usando GCMAES128 para ambos.

Na tabela anterior:

  • IKEv2 corresponde ao Modo Principal ou Fase 1.
  • O IPsec corresponde ao Modo Rápido ou à Fase 2.
  • O Grupo DH especifica o Grupo Diffie-Hellmen usado no Modo Principal ou na Fase 1.
  • O Grupo PFS especifica o grupo de Diffie-Hellmen usado no Modo Rápido ou fase 2.
  • O tempo de vida de SA do modo Principal IKEv2 é corrigido em 28.800 segundos nos gateways de VPN robustos do Azure Stack Hub.

A tabela abaixo lista os Grupos Diffie-Hellman correspondentes que têm suporte na política personalizada:

Grupo Diffie-Hellman DHGroup PFSGroup Comprimento da chave
1 DHGroup1 PFS1 MODP de 768 bits
2 DHGroup2 PFS2 MODP de 1024 bits
14 DHGroup14 PFS2048 MODP de 2048 bits
DHGroup2048
19 ECP256 ECP256 ECP de 256 bits
20 ECP384 ECP384 ECP de 384 bits
24 DHGroup24 PFS24 MODP de 2048 bits

Conectar o Azure Stack Hub robusto ao Azure usando o Azure ExpressRoute

Visão geral, suposições e pré-requisitos

O Azure ExpressRoute permite estender as redes locais para a nuvem da Microsoft. Você usa uma conexão privada fornecida por um provedor de conectividade. O ExpressRoute não é uma conexão VPN pela Internet pública.

Para obter mais informações sobre o Azure ExpressRoute, consulte a Visão geral do ExpressRoute.

Suposições

Este artigo supõe que:

  • Você tem um conhecimento prático do Azure.
  • Você tem uma compreensão básica do Azure Stack Hub robusto.
  • Você tem uma compreensão básica da rede.

Pré-requisitos

Para conectar o Azure Stack Hub robusto e o Azure usando o ExpressRoute, você deve atender aos seguintes requisitos:

  • Um circuito do ExpressRoute provisionado por meio de um provedor de conectividade.
  • Uma assinatura do Azure para criar um circuito do ExpressRoute e VNets no Azure.
  • Um roteador que dá suporte a:
    • Conexões VPN site a site entre sua interface LAN e o gateway multilocatário robusto do Azure Stack Hub.
    • criar vários VRFs (Roteamento e Encaminhamento Virtual) se houver mais de um locatário em sua implantação robusta do Azure Stack Hub.
  • Um roteador que tem:
    • Uma porta WAN conectada ao circuito do ExpressRoute.
    • Uma porta LAN conectada ao gateway multilocatário robusto do Azure Stack Hub.

Arquitetura de rede do ExpressRoute

A figura a seguir mostra os ambientes do Azure Stack Hub robustos e do Azure depois de concluir a configuração do ExpressRoute usando os exemplos neste artigo:

Arquitetura de rede do ExpressRoute

A figura a seguir mostra como vários locatários se conectam da infraestrutura robusta do Azure Stack Hub por meio do roteador do ExpressRoute para o Azure:

Arquitetura de rede do ExpressRoute multilocatário