Introdução à rede resistente ao Hub de Azure Stack

Visão geral do design de rede

Design de rede física

A solução resistente ao Hub de Azure Stack requer uma infraestrutura física resiliente e altamente disponível para dar suporte a seus serviços e operação. Uplinks de ToR para alternâncias de borda são limitados a mídia SFP + ou SFP28 e velocidades de 1 GB, 10 GB ou 25 GB. Verifique com o fornecedor de hardware do OEM (fabricante original do equipamento) para disponibilidade.

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

Rede física resistente ao Hub de Azure Stack

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 da rede lógica, os sites de rede são criados para definir:

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

Todos os 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 que você deve planejar:

Rede lógica Descrição Tamanho
IP virtual público (VIP) O Hub Azure Stack resistente usa um total de 31 endereços desta rede. Oito endereços IP públicos são usados para um pequeno conjunto de serviços resistentes de Hub de Azure Stack e o restante são usados por VMs de locatário. se você planeja usar o serviço de aplicativo e os provedores de recursos de SQL, serão usados 7 mais endereços. 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 dedicado e endereços de loopback atribuídos ao comutador. / 26
Infraestrutura Usado para que os componentes internos resistentes ao Hub de Azure Stack se comuniquem. /24
Privados 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 de baseboard nos hosts físicos. / 26

Infraestrutura de rede

A infraestrutura de rede para Azure Stack Hub resistente consiste em várias redes lógicas configuradas nos comutadores. O diagrama a seguir mostra essas redes lógicas e como elas se integram com os comutadores Top-of-rack (TOR), Baseboard Management Controller e Border (Customer Network).

Diagrama de rede lógica resistente do hub de Azure Stack:

Rede lógica resistente do hub de Azure Stack

Rede BMC

Essa rede é dedicada à conexão de todos os controladores de gerenciamento de placa básica (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ó do BMC. Se presente, o host de ciclo de vida do hardware (HLH) 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 VM de implantação (DVM). O DVM é usado durante a implantação resistente do hub de Azure Stack 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 de sua rede corporativa (por exemplo: NTP, DNS e Azure). Para obter mais informações sobre requisitos de conectividade, consulte a seção NAT em integração de firewall de Azure Stack Hub resistente.

Rede privada

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

  • rede Armazenamento: uma rede/25 (128 IPs) usada para dar suporte ao uso de espaços diretos e tráfego de armazenamento de protocolo SMB e migração dinâmica de VM.
  • Rede IP virtual interna: a/25 rede 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 é de/20 (4096 IPs) de espaço IP privado. Essa rede é privada para o sistema de Azure Stack Hub resistente. Ele não roteia além dos dispositivos de alternância de borda do sistema de Azure Stack Hub resistente e pode ser reutilizado em vários sistemas de Azure Stack Hub resistentes. Embora a rede seja privada para Azure Stack Hub resistente, ela não deve se sobrepor a outras redes no datacenter. Para obter orientação sobre o espaço IP privado, recomendamos seguir o RFC 1918.

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

Rede de infraestrutura resistente do hub de Azure Stack

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

Rede VIP pública

A rede VIP pública é atribuída ao controlador de rede no Hub Azure Stack resistente. Não é uma rede lógica no comutador. O SLB usa o pool de endereços e atribui/32 redes para cargas de trabalho de locatário. Na tabela de roteamento de comutador, esses/32 IPs são anunciados como uma rota disponível via Border Gateway Protocol (BGP). Essa rede contém endereços públicos que são acessíveis externamente. A infraestrutura resistente do hub de Azure Stack 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) para 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 de ponto a ponto roteáveis/30 (dois IPs de host) e os loopbacks. Essas são sub-redes dedicadas/32 para gerenciamento de switch em banda e ID do roteador BGP. Esse intervalo de endereços IP deve ser roteável fora da solução de Azure Stack Hub resistente ao seu datacenter. Os endereços IP podem ser privados ou públicos.

Alternar rede de gerenciamento

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

Visão geral do design de DNS

Para acessar pontos de extremidade resistentes do Hub Azure Stack (portal, adminportal, Gerenciamento, adminmanagement) de fora do hub de Azure Stack resistente, você deve integrar os serviços DNS resistentes ao Hub de Azure Stack com os servidores DNS que hospedam as zonas DNS que você deseja usar no Hub Azure Stack resistente.

Namespace DNS resistente ao Hub de Azure Stack

É necessário fornecer algumas informações importantes relacionadas ao DNS quando você implanta Azure Stack Hub resistente.

Campo Descrição Exemplo
Região A localização geográfica do seu hub de Azure Stack implantação resistente. leste
Nome de domínio externo O nome da zona que você deseja usar para a implantação resistente do hub de Azure Stack. cloud.fabrikam.com
Nome de domínio interno O nome da zona interna usada para serviços de infraestrutura no Hub Azure Stack resistente. É integrado ao serviço de diretório e privado (não acessível de fora da implantação resistente do hub de Azure Stack). azurestack. local
Encaminhadores DNS Servidores DNS que são usados para encaminhar consultas DNS, zonas DNS e registros que são hospedados fora do Hub Azure Stack resistentes, 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 da instância de função de infraestrutura resistente do hub de Azure Stack tenham. Se não for fornecido, o padrão será "AZS". azs

O FQDN (nome de domínio totalmente qualificado) do seu hub de Azure Stack implantação e pontos de extremidade resistentes é a combinação do parâmetro de região e o parâmetro de nome de domínio externo. Usando os valores dos exemplos na tabela anterior, o FQDN para esta implantação de Azure Stack Hub resistente seria: East.Cloud.fabrikam.com

Como tal, exemplos de alguns dos pontos de extremidade para essa implantação seriam semelhantes às 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 resistente ao Hub de Azure Stack, as seguintes condições são necessárias:

  • A zona fabrikam.com é registrada com um registrador de domínio, servidor DNS corporativo interno ou ambos. O registro depende de seus 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 na implantação resistente do hub de Azure Stack.

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

Rótulos de nome DNS

O Hub de Azure Stack resistente 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 de DNS são uma maneira conveniente para os usuários acessarem aplicativos e serviços hospedados no Hub de Azure Stack resistentes 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 de 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 resistente ao Hub de Azure Stack. 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, você deve integrar os servidores DNS. Incluindo servidores que hospedam a zona DNS externa para Azure Stack Hub resistente 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 resistentes ao Hub de Azure Stack, portanto, você deve criar uma delegação adicional ou uma regra de encaminhamento condicional.

Para obter mais informações sobre como o rótulo de nome DNS funciona, consulte "usando DNS" em Azure Stack Hub resistente.

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 Hub de Azure Stack resistentes inclui servidores DNS autoritativos e recursivos. Os servidores recursivos são usados para resolver nomes de tudo, exceto a zona privada interna, e a zona DNS pública externa para a implantação resistente do hub de Azure Stack.

Resolvendo nomes DNS externos do hub de Azure Stack resistentes

Para resolver nomes DNS para pontos de extremidade fora do hub de Azure Stack resistentes (por exemplo: www.Bing.com), você deve fornecer servidores DNS para Azure Stack Hub resistente a solicitações DNS encaminhadas, para as quais Azure Stack Hub resistente não é autoritativo. Os servidores DNS que Azure Stack as solicitações de encaminhamentos resistentes ao hub são necessários na planilha de implantação (no campo encaminhador de DNS). Forneça pelo menos dois servidores neste campo para tolerância a falhas. Sem esses valores, Azure Stack implantação resistente ao 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 Hub Azure Stack resistente. Os firewalls podem ajudar a se defender de coisas como ataques de DDOS (negação de serviço distribuído), detecção de intrusão e inspeção de conteúdo. No entanto, eles também podem se tornar um afunilamento de taxa de transferência para 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 Azure Resource Manager (administrador), portal do administrador e 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 Azure Stack Hub resistente de dentro da rede e não da Internet.

Para organizações empresariais, a rede externa pode ser a rede corporativa existente. Nesse cenário, você deve publicar pontos de extremidade para operar Azure Stack Hub resistente à rede corporativa.

Conversão de endereços de rede

NAT (conversão de endereços de rede) é o método recomendado para permitir que a máquina virtual de implantação (DVM) acesse recursos externos durante a implantação. Também para as VMs do ERCS (console de recuperação de emergência) ou o ponto de extremidade privilegiado (PEP) 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, não é recomendável fazer isso porque ele 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 requer um IP público por IP de usuário no pool. Outra opção é uma NAT de muitos para um que requer 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 de SDN (rede definida pelo software). Os usuários devem entrar em contato com o operador de Azure Stack Hub resistente para obter seus VIPs publicados e para atualizar a lista de portas.
  • Embora o uso de NAT limite a experiência do usuário, ele dá controle total ao operador sobre as solicitações de publicação.
  • Para cenários de nuvem híbrida com o Azure, considere que o Azure não dá suporte à configuração de um túnel 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 de Azure Stack Hub resistente. Se houver suporte em atualizações futuras, serão fornecidas diretrizes sobre como habilitar a interceptação de SSL para o Hub de Azure Stack resistente.

Cenário de firewall de implantação de borda

Em uma implantação de borda, Azure Stack Hub resistente é 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 ele 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), em que ele dá suporte apenas à configuração de firewall ativo-ativo. O cenário 2 conta com o ECMP (vários caminhos de custo igual) com o roteamento de BGP ou 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, os 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 Experimente toda a experiência em nuvem totalmente controlada como em uma nuvem pública, como o Azure.

Cenário de firewall de borda resistente ao Hub de Azure Stack

cenário de firewall de rede Enterprise intranet ou de perímetro

Em uma implantação de intranet ou de perímetro empresarial, Azure Stack Hub resistente é implantado em um firewall de várias zonas, ou entre o firewall de borda e o firewall de rede corporativa interna. Em seguida, seu tráfego é distribuído entre a rede de perímetro segura (ou a DMZ) e as zonas não seguras, conforme 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 do NAT de firewall. Ele é normalmente acessível de dentro de seu datacenter por meio da rede interna. Todas as redes resistentes ao Hub de Azure Stack devem residir na zona segura, exceto para o pool VIP público da rede externa.
  • Zona do perímetro. A rede de perímetro é onde os 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 (invasão) enquanto ainda permite o tráfego de entrada especificado da Internet. Somente o pool vip público de rede externa Azure Stack Hub robusto deve residir na zona DMZ.
  • Zona não segura. A rede externa, a Internet. A implantação Azure Stack Hub com robustez na zona não segura não é recomendada.

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 da solução precisam conhecer.

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 Azure Stack Hub robusta e uma rede virtual no Azure. Você também pode enviar o 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. Azure Stack Hub robustez 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 Azure Stack Hub robustos, revise as considerações para Azure Stack Hub rede robusta. Você aprende como as configurações para Azure Stack Hub robustas diferem do Azure.

No Azure, a produtividade de largura de banda da SKU do gateway de VPN que você escolher deve ser dividida entre todas as conexões conectadas ao gateway. No Azure Stack Hub, no entanto, 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, a SKU básica do gateway de VPN 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 estarão disponíveis para a outra conexão.
  • No Azure Stack Hub, cada conexão com o SKU básico do gateway de VPN é alocada com 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ê está usando. 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 tem suporte apenas para o tipo de VPN baseado em rota. Se o dispositivo dá suporte apenas a VPNs baseadas em políticas, não há suporte para conexões com esses dispositivos Azure Stack Hub com robustez. Além disso, Azure Stack Hub robusto não dá suporte ao uso de seletores de tráfego baseados em políticas para gateways baseados em rota no momento, porque não há suporte para configurações de política IKE/IPSec personalizadas.

  • PolicyBased:VPNs baseadas em políticas 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 sua rede local e a rede Azure Stack Hub VNet robusta. 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:VPNs baseadas em rota usam rotas configuradas na tabela de roteamento ou encaminhamento de IP. O encaminha pacotes diretos 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 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 local 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 as descrições nas seções a seguir podem ajudá-lo a selecionar uma topologia de conexão para corresponder às suas necessidades. Os diagramas mostram as principais topologias de linha de base, mas é possível criar configurações mais complexas usando os diagramas como um guia.

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

Site a site

Uma conexão de gateway de VPN S2S (site a site) é uma conexão por túnel VPN IPsec/IKE (IKEv2). Esse tipo de conexão requer um dispositivo VPN que está localizado localmente e recebe um endereço IP público. Esse dispositivo não pode estar 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 um 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 Azure Stack Hub robusto, especifique o SKU do gateway que deseja usar. Há suporte para as seguintes SKUs de gateway de VPN:

  • Basic
  • Standard
  • Alto Desempenho

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

Azure Stack Hub robustez não dá suporte à SKU do gateway de Desempenho Ultra, que é usada exclusivamente com o Express Route.

Considere o seguinte ao selecionar o SKU:

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

Disponibilidade do gateway

Cenários de alta disponibilidade só podem ser configurados no 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 tem suporte apenas para a configuração ativa/passiva.

Failover

Há três VMs de infraestrutura de gateway de vários locatários 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 neles 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 falhará 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 produtividade 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

Notas de tabela

(1) – A produtividade da VPN não é uma produtividade garantida para conexões entre locais pela Internet. É a medida máxima de produtividade possível.
(2) – Túneis máximos é o total por Azure Stack Hub implantação robusta para todas as assinaturas.
(3) – Não há suporte para o roteamento de BGP para o SKU Básico.

Importante

Somente uma conexão VPN site a site pode ser criada entre duas Azure Stack Hub implantações robustas. Isso ocorre devido a uma limitação na plataforma que permite apenas uma única conexão VPN com o mesmo endereço IP. Como Azure Stack Hub robusto aproveita o gateway multi-locatá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 Azure Stack Hub robustos.

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 usa um único endereço IP. Azure Stack Hub robustez não permite que mais de um recurso de gateway de rede local seja criado usando o mesmo endereço IP.**

Parâmetros IPsec/IKE

Ao configurar uma conexão VPN em Azure Stack Hub robustez, você deve configurar a conexão em ambas as extremidades. Se você estiver configurando uma conexão VPN entre Azure Stack Hub robusto e um dispositivo de hardware, esse dispositivo poderá solicitar configurações adicionais. Por exemplo, uma opção 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 configurações de IPSec/IKE diferentes para trabalhar com seu dispositivo VPN, há mais configurações disponíveis para configurar a 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
Algoritmos & de hash de criptografia 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 criptografia (criptografia) GCMAES256
Algoritmos & de hash de criptografia (autenticação) GCMAES256
Tempo de vida da SA (Tempo) 27.000 segundos
Tempo de vida de SA (Quilobytes) 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 IPsec e IKE dá suporte a uma ampla variedade de algoritmos criptográficos em várias combinações. Para ver quais parâmetros têm suporte no Azure Stack Hub para atender aos requisitos de conformidade ou segurança, consulte 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 estas políticas:

  • A política IPsec/IKE funciona apenas 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. Conexões site a site não podem ser estabelecidas se as políticas são incompatíveis.

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

Esta seção descreve o fluxo de trabalho necessário para criar e atualizar a política de 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. Crie uma política IPsec/IKE com algoritmos e parâmetros selecionados.
  4. Crie uma conexão IPSec com a política IPsec/IKE.
  5. Adicionar/atualizar/remover uma política 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 por Azure Stack Hub clientes robustos:

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íticas Azure Stack Hub robustos.

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 tempo de vida do SA são apenas especificações locais, eles não precisam corresponder.

Se o GCMAES for usado como para o algoritmo de Criptografia IPsec, você deverá selecionar o mesmo algoritmo GCMAES e o comprimento da chave para integridade de 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 Diffie-Hellmen usado no Modo Rápido ou na Fase 2.
  • O tempo de vida sa do modo principal IKEv2 é fixo em 28.800 segundos no Azure Stack Hub gateways de VPN robustos.

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

Conexão Azure Stack Hub robusto para o Azure usando 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 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 da Azure Stack Hub robusta.
  • Você tem uma compreensão básica da rede.

Pré-requisitos

Para se conectar Azure Stack Hub 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 Azure Stack Hub gateway multi-locatário robusto.
    • criando várias VRFs (Roteamento Virtual e Encaminhamento) se houver mais de um locatário em sua Azure Stack Hub implantação robusta.
  • Um roteador que tem:
    • Uma porta WAN conectada ao circuito do ExpressRoute.
    • Uma porta LAN conectada ao gateway Azure Stack Hub multi-locatário robusto.

Arquitetura de rede do ExpressRoute

A figura a seguir mostra Azure Stack Hub ambientes 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 Azure Stack Hub infraestrutura robusta por meio do roteador do ExpressRoute para o Azure:

Arquitetura de rede do ExpressRoute multi locatário