Introdução à rede do Datacenter Modular (MDC)

Conteúdo do pacote

A solução Datacenter Modular do Azure (MDC) é fornecida com o equipamento de rede adicional mencionado neste artigo. Esse equipamento é usado para conectar o contêiner à sua rede.

Confirme a óptica do comutador que corresponde ao seu ambiente.

Quantidade	Tipo	Modelar
12	12x QSFP-40G	"SR"
12	12x SFP+ 10 GB	"SR"
12	12x SFP 1G	"SR"
12	12x QSFP-40G	"LR"
12	12x SFP+ 10 GB	"LR"
12	12x SFP 1G	"LR"

Visão geral do projeto de rede

Projeto de rede física

A solução do MDC requer uma infraestrutura física resiliente e altamente disponível para dar suporte a seus serviços e à operação. Os uplinks do topo do rack (TOR) para os comutadores de borda são limitados à mídia SFP+ ou SFP28 e às velocidades de 1 GB, 10 GB ou 40 GB.

O diagrama a seguir apresenta nosso projeto recomendado para o MDC.

Projeto de rede lógica

Um projeto 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, máquinas virtuais (MVs) e serviços. Como parte da criação da rede lógica, os sites de rede são criados para definir a rede:

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

Todas essas VLANs e sub-redes estão associadas à 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 devem ser planejados.

Rede lógica	Descrição	Tamanho
IP virtual público (VIP)	O MDC 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 MDC, e o restante é usado por MVs de locatários. Se você planeja usar o Serviço de Aplicativo do Azure e os provedores de recursos SQL, serão usados mais sete 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)
Infraestrutura do comutador	Endereços IP ponto a ponto dedicados para propósitos de roteamento, interfaces de gerenciamento dedicadas de comutadores e endereços de loopback atribuídos ao comutador.	/26
Infraestrutura	Usado para os componentes internos do MDC se comunicarem.	/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 BMCs nos hosts físicos.	/26
Isilon	Usado para se comunicar com o armazenamento Isilon.	1x /25 TOR 1x /25 BMC (gerenciamento)

Infraestrutura da rede

A infraestrutura de rede para o MDC consiste em várias redes lógicas que são configuradas nos comutadores. O diagrama a seguir mostra essas redes lógicas e como elas se integram aos comutadores topo de rack (TOR), BMC e de borda (rede do cliente).

Rede BMC

Essa rede é dedicada a conectar todos os BMCs (também conhecidos como processadores de serviço) à rede de gerenciamento. Os exemplos incluem iDRAC, iLO e iBMC. Apenas uma conta do BMC é usada para estabelecer comunicação com qualquer nó do BMC. Se estiver presente, o HLH (Hardware Lifecycle Host, host do ciclo de vida do hardware) está localizado nessa rede e pode fornecer software específico de OEM para manutenção ou monitoramento de hardware.

O HLH também hospeda a MV de implantação (DVM). O DVM é usado durante a implantação do MDC 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. Os exemplos incluem NTP, DNS (Sistema de Nomes de Domínio) e Azure. Para obter mais informações sobre os requisitos de conectividade, consulte a seção de tradução de endereços de rede (NAT) na integração do firewall do MDC.

Rede privada

A rede /20 (4096 IPs de host) é privada para a região do MDC. Ele não se expande além dos dispositivos de comutação de fronteira da região do MDC. 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 do Armazenamento Direto de Espaços de Armazenamento e do Bloco de Mensagens do Servidor (SMB) e à migração em tempo real de MVs.
• 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 apenas interno entre contêineres que executam serviços de infraestrutura.

O tamanho da rede privada alterada é /20 (4096 IPs) de espaço IP privado. Essa rede é privada para o sistema MDC. Ele não é roteado além dos dispositivos de comutação de borda do sistema MDC e pode ser reutilizado em vários sistemas MDC. Embora a rede seja privada para o MDC, ela não deve se sobrepor a outras redes no datacenter. Para obter orientação sobre o espaço IP privado, recomendamos que você siga a RFC 1918.

O espaço IP privado /20 é dividido em várias redes que permitem que a infraestrutura do sistema MDC seja executada em contêineres em versões futuras. Esse espaço IP privado permite esforços constantes para reduzir o espaço IP roteável necessário antes da implantação.

Rede de infraestrutura do MDC

A rede /24 é dedicada aos componentes internos do MDC para que eles possam se comunicar e trocar dados entre si. Essa sub-rede pode ser roteada externamente da solução MDC para o seu datacenter. Não recomendamos s o uso de endereços IP públicos ou roteáveis pela Internet nesta sub-rede. Esta rede é anunciada na borda, mas a maioria de seus endereços IP está protegida por listas de controle de acesso. Os IPs permitidos para acesso estão em um intervalo pequeno, equivalente em tamanho a uma rede /27. Os IPs hospedam serviços como o PEP (privileged endpoint, ponto de extremidade privilegiado) e o backup do MDC.

Rede VIP pública

A rede VIP pública é atribuída ao controlador de rede no MDC. 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 roteiros do comutador, esses IPs /32 são anunciados como uma rota disponível por meio do BGP (Border Gateway Protocol, protocolo de gateway de borda). Essa rede contém endereços públicos que podem ser acessados externamente. A infraestrutura do MDC reserva os primeiros 31 endereços dessa rede VIP pública, enquanto os restantes são usados pelas MVs de locatários. O tamanho da rede nessa sub-rede pode variar de um mínimo de /26 (64 hosts) a um máximo de /22 (1.022 hosts). Recomendamos que você planeje uma rede /24.

Rede de infraestrutura de comutadores

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

Rede de gerenciamento de comutadores

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

Rede Isilon

Há duas redes /25. Um fica no comutador TOR e um /25 é usado no comutador BMC para gerenciamento.

Visão geral do projeto do DNS

Para acessar o gerenciamento do (portal, adminportal e o adminmanagement do portal) de pontos de extremidade do MDC de fora do MDC, é necessário integrar os serviços DNS do MDC com os servidores DNS que hospedam as zonas DNS que você deseja usar no MDC.

Namespace do DNS do MDC

Você precisa fornecer algumas informações importantes relacionadas ao DNS ao implantar a solução MDC.

Campo	Descrição	Exemplo
Região	A localização geográfica de sua implantação de MDC.	leste
Nome de domínio externo	O nome da zona que você deseja usar para a implantação do MDC.	cloud.fabrikam.com
Nome de domínio interno	O nome da zona interna usada para serviços de infraestrutura no MDC. Ele é integrado ao serviço de diretório e é privado (não pode ser acessado de fora da implantação do MDC).	azurestack.local
Encaminhadores DNS	Os servidores DNS usados para encaminhar consultas DNS, zonas DNS e registros hospedados fora do MDC, seja na intranet corporativa ou na Internet pública. Você pode editar o valor do encaminhador de DNS com o cmdlet Set-AzSDnsForwarder após a implantação.
Prefixo de nomenclatura (opcional)	O prefixo de nomenclatura que você deseja que os nomes de máquina da instância da função de infraestrutura do MDC tenham. Se não for fornecido, o padrão será azs.	azs

O FQDN (fully qualified domain name, nome de domínio totalmente qualificado) da implantação e dos pontos de extremidade do MDC é a combinação do parâmetro de região e do parâmetro de nome de domínio externo. Com os valores dos exemplos da tabela anterior, o FQDN para essa implantação de MDC seria east.cloud.fabrikam.com.

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 em uma implantação do MDC, são necessárias as seguintes condições:

• A zona fabrikam.com está registrada em um registrador de domínios, em um servidor DNS corporativo interno ou em ambos. O registro depende dos requisitos de resolução do seu nome.
• 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 a partir da implantação do MDC.

Para resolver nomes DNS para pontos de extremidade e instâncias do MDC de fora do MDC, você deve integrar os servidores DNS. Inclua os servidores que hospedam a zona DNS externa para o MDC com os servidores DNS que hospedam a zona pai que você deseja usar.

Rótulo de nome DNS

O MDC 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 alcançarem aplicativos e serviços hospedados no MDC por nome. O rótulo de nome DNS usa um namespace ligeiramente diferente dos pontos de extremidade de infraestrutura. Seguindo o exemplo de namespace anterior, o namespace para rótulos de nomes DNS seria *.east.cloudapp.cloud.fabrikam.com.

Se um locatário especificar MyApp no campo de rótulo 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 MDC. O FQDN resultante seria myapp.east.cloudapp.cloud.fabrikam.com.

Se quiser aproveitar essa funcionalidade e usar esse namespace, você deverá integrar os servidores DNS. Inclua os servidores que hospedam a zona DNS externa do MDC 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 MDC, portanto, você deve criar uma delegação adicional ou uma regra de encaminhamento condicional.

Para obter mais informações sobre como funciona o rótulo de nome DNS, consulte “Uso do DNS” na documentação do MDC.

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 MDC inclui servidores DNS autoritativos e recursivos. Os servidores recursivos são usados para resolver os nomes de tudo, exceto da zona privada interna e da zona DNS pública externa para essa implantação do MDC.

Resolver nomes DNS externos a partir do MDC

Para resolver nomes DNS para pontos de extremidade fora do MDC (por exemplo, www.bing.com), você deve fornecer servidores DNS para que o MDC encaminhe solicitações DNS, para as quais o MDC não é autoritativo. Os servidores DNS para os quais o MDC encaminha solicitações são necessários na Planilha de implantação (no campo encaminhador de DNS). Forneça pelo menos dois servidores nesse campo para tolerância a falhas. Sem esses valores, a implantação do MDC falha. Após a implantação, você pode editar o valor do encaminhador DNS com o cmdlet Set-AzSDnsForwarder.

Visão geral do projeto do firewall

Recomendamos que você use um dispositivo de firewall para proteger o MDC. 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. Eles também podem afunilar a taxa de transferência de serviços de armazenamento do Azure, como blobs, tabelas e filas.

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

Os pontos de extremidade do Azure Resource Manager (administrador), o portal do administrador e o Azure 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 por somente administrar o MDC de dentro de sua rede e não pela Internet.

Para empresas, a rede externa pode ser a rede corporativa existente. Nesse cenário, você deve publicar pontos de extremidade para operar o MDC por meio da rede corporativa.

Conversão de endereços de rede

Recomendamos o método NAT para permitir que o DVM acesse recursos externos durante a implantação. Também recomendamos NAT para as MVs do ERCS (Emergency Recovery Console, console de recuperação de emergência) ou 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. Não recomendamos essa opção porque ela 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 no gerenciamento de regras de firewall, pois os usuários controlam seus próprios pontos de extremidade e publicam regras na pilha de rede definida por software. Os usuários devem entrar em contato com o operador do MDC para que seus VIPs sejam publicados e para 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, recomendamos que você desative qualquer interceptação de SSL (por exemplo, descarregamento de descriptografia) em todo o tráfego do MDC. Se houver suporte em atualizações futuras, serão fornecidas diretrizes sobre como habilitar a interceptação de SSL para o MDC.

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

Em uma implantação de borda, o MDC é implantado diretamente atrás do firewall ou do roteador de edge. Nesses cenários, há suporte para o firewall estar acima da borda (Cenário 1), onde ele oferece suporte às configurações de firewall ativo-ativo e ativo-passivo. Ele também pode atuar como dispositivo de borda (Cenário 2), no qual oferece suporte apenas à configuração de firewall ativo-ativo. O cenário 2 depende do multipath de custo igual com BGP ou roteiros estáticos 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. Por motivos de segurança, os IPs públicos roteáveis 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 rede ou de perímetro ou intranet empresarial

Em uma implantação de perímetro ou intranet empresarial, o MDC é implantado em um firewall com várias zonas ou entre o firewall de borda e o firewall interno da rede corporativa. 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:

• 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 do firewall. Normalmente, ele pode ser acessado de dentro de seu datacenter por meio da rede interna. Todas as redes do MDC devem residir na zona segura, exceto o pool VIP público da rede externa.
• Zona do perímetro: é na rede de perímetro que normalmente são implantados os aplicativos externos ou voltados para a Internet, como servidores web. Ela é monitorado normalmente por um firewall para evitar ataques como DDoS e invasão (hacking) enquanto ainda permite o tráfego de entrada especificado da Internet. Somente o pool VIP público da rede externa do MDC deve residir na zona DMZ.
• Zona não segura: a rede externa, a Internet. Não recomendamos que você implante o MDC na zona não segura.

Visão geral do projeto do VPN

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

Antes de poder enviar tráfego de rede entre a rede virtual do Azure e o site local, você deve criar um gateway de rede virtual (VPN) 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 de forma segura entre uma rede virtual no MDC e uma rede virtual no Azure. Você também pode enviar tráfego de forma segura entre uma rede virtual e outra rede que esteja conectada a um dispositivo VPN.

Ao criar um gateway de rede virtual, especifique o tipo de gateway que você deseja criar. O MDC oferece 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 em vários sites.

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

No Azure, a taxa de transferência de bandwidth para o gateway VPN SKU que você escolher deve ser dividida entre todas as conexões conectadas ao gateway. Mas no MDC, o valor da bandwidth para o gateway VPN SKU é aplicado a cada recurso de conexão conectado ao gateway. Por exemplo:

• No Azure, o gateway VPN básico SKU pode acomodar aproximadamente 100 Mbps de taxa de transferência agregada. Se você criar duas conexões para esse gateway de VPN e uma conexão estiver usando 50 Mbps de bandwidth, então 50 Mbps estarão disponíveis para a outra conexão.
• No MDC, cada conexão com o gateway básico de VPN SKU recebe 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 (site a site) exigem um dispositivo VPN. Alguns dispositivos VPN recebem suporte apenas de um determinado tipo de VPN.

Importante

Atualmente, o MDC oferece suporte apenas ao tipo de VPN baseada em rota. Se o seu dispositivo oferecer suporte apenas a VPNs baseadas em políticas, não haverá suporte para conexões com esses dispositivos a partir do MDC. No momento, o MDC também não oferece suporte ao uso de seletores de tráfego baseados em políticas para gateways baseados em rotas porque não há suporte para configurações personalizadas de políticas IPsec/IKE.

• PolicyBased: as 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 virtual do MDC. A política, ou seletor de tráfego, geralmente é uma lista de acesso na configuração do dispositivo VPN. PolicyBased tem suporte no Azure, mas não no MDC.
• RouteBased: as VPNs baseadas em rota usam rotas configuradas na tabela de encaminhamento ou roteiros de IP. As rotas direcionam os 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 seletor de tráfego, para VPNs RouteBased é configurada como qualquer para qualquer (ou usa coringas). Por padrão, eles não podem ser alterados. O valor para um tipo de VPN RouteBased é RouteBased.

Configurar um gateway de VPN

Uma conexão de gateway VPN conta com vários recursos que são configurados com definiçõ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 que você escolheu para cada recurso são essenciais para a criação de 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 recursos que você talvez 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, é possível visualizar informações e diagramas de topologia sobre as seguintes conexões de gateway 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 que atenda à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 guia.

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

Site a site

Uma conexão de gateway VPN site a site é uma conexão em um túnel VPN IPsec/IKE (IKEv2). Esse tipo de conexão requer um dispositivo VPN localizado no local e que recebe um endereço IP público. Esse dispositivo não pode estar localizado atrás de um NAT. As conexões site a site 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ê cria mais de uma conexão VPN a partir do seu gateway de rede virtual e, normalmente, conecta-se a vários sites locais. Quando você trabalha com várias conexões, deve usar um tipo de VPN baseado em rota (conhecido como gateway dinâmico quando você trabalha com redes virtuais clássicas). Como cada rede virtual pode ter apenas um gateway de VPN, todas as conexões por meio do gateway compartilham a bandwidth disponível.

SKUs de gateway

Ao criar um gateway de rede virtual para o MDC, você especifica a SKU do gateway que deseja usar. Os seguintes SKUs de gateway de VPN têm suporte:

• Básico
• Padrão
• Alto Desempenho

A seleção de uma SKU de gateway mais alta aloca mais CPUs e largura de banda de rede para o gateway. Como resultado, o gateway pode oferecer suporte a uma maior taxa de transferência de rede para a rede virtual.

O MDC não oferece suporte à SKU de gateway Ultra Performance, usada exclusivamente com o Azure ExpressRoute. Considere os seguintes pontos ao selecionar a SKU:

• O MDC não oferece suporte a gateways baseados em políticas.
• BGP não tem suporte na SKU Básica.
• As configurações coexistentes de gateway ExpressRoute-VPN não têm suporte no MDC.

Disponibilidade do gateway

Os 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 oferece disponibilidade por meio de configurações ativas/ativas e ativas/passivas, o MDC oferece suporte apenas à configuração ativa/passiva.

Failover

Há três VMs de infraestrutura de gateway multilocatário no MDC. Duas dessas MVs estão no modo ativo. A terceira MV está em modo redundante. As MVs ativas permitem a criação de conexões VPN nelas. A MV redundante só aceita conexões VPN se ocorrer um failover. Se uma MV de gateway ativo ficar indisponível, a conexão VPN passará para a MV 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 agregada estimada pela SKU do gateway.

Tipo de gateway	Taxa de transferência do gateway de VPN (1)	Máximo de túneis IPsec do gateway de VPN (2)
SKU Básico (3)	100 Mbps	20
SKU Standard	100 Mbps	20
SKU de alto desempenho	200 Mbps	10

Observações da tabela :

(1) A taxa de transferência da VPN não é uma taxa de transferência garantida para conexões entre instalações pela Internet. É a medida de taxa de transferência máxima possível.

(2) O máximo de túneis é o total por implantação de MDC para todas as assinaturas.

(3) Os roteiros BGP não têm suporte para a SKU básica.

Importante

Somente uma conexão VPN site a site pode ser criada entre duas implantações de MDC. Essa restrição ocorre porque uma limitação na plataforma permite apenas uma única conexão VPN para o mesmo endereço IP. Como o MDC usa o gateway multilocatário, que usa um único IP para todos os gateways de VPN no sistema MDC, pode haver apenas uma conexão VPN entre dois sistemas MDC.

Essa limitação também se aplica à conexão de mais de uma conexão VPN site a site a qualquer gateway VPN que use um único endereço IP. O MDC 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 MDC, você deve configurar a conexão em ambas as extremidades. Se você estiver configurando uma conexão VPN entre o MDC e um dispositivo de hardware, esse dispositivo poderá solicitar configurações adicionais. Por exemplo, o dispositivo pode solicitar um comutador ou roteador que esteja atuando como um gateway de VPN.

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

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

Propriedade	Valor
Versão do IKE	IKEv2
Grupo Diffie-Hellman	ECP384
Método de autenticação	Chave pré-compartilhada
Criptografia & 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 do IKE	IKEv2
Criptografia & algoritmos de hash (criptografia)	GCMAES256
Criptografia & algoritmos de hash (autenticação)	GCMAES256
Tempo de vida da SA (tempo)	27.000 segundos
Tempo de vida da 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 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 MDC 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 aplicá-la 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 nos SKUs de gateway Standard e alto desempenho (baseados 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 de 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 instalações.
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 ou remover uma política IPsec/IKE para uma conexão existente.

Suporte para algoritmos de criptografia e restrições de chave

A tabela a seguir lista os algoritmos criptográficos com suporte e as forças das chaves configuráveis pelos clientes do MDC.

IPsec/IKEv2	Opções
Criptografia IKEv2	AES256, AES192, AES128, DES3, DES
Integridade IKEv2	SHA384, SHA256, SHA1, MD5
Grupo DH	ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, nenhum
Criptografia IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, nenhum
Integridade 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 são usados se não forem especificados).
	Segundos (número inteiro, mín. 300/padrão 27.000 segundos)
	KBytes (número inteiro, mín. 1024/padrão 102.400.000 KBytes)
Seletor de tráfego	Os seletores de tráfego baseados em políticas não têm suporte no MDC.

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 da SA são apenas especificações locais. Eles não precisam ser iguais.

Se o GCMAES for usado como algoritmo de criptografia do IPsec, você deverá selecionar o mesmo algoritmo GCMAES e o mesmo comprimento de chave para a integridade do IPsec. Por exemplo, use 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-Hellman utilizado no Modo Principal ou na Fase 1.
• O Grupo PFS especifica o Grupo Diffie-Hellman usado no Modo Rápido ou Fase 2.
• O tempo de vida da SA de modo principal IKEv2 é fixo em 28.800 segundos nos gateways de VPN do MDC.

A tabela a seguir 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

Conecte o MDC ao Azure usando o Azure ExpressRoute

Visão geral, premissas 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 pressupõe que você tenha um:

• Conhecimento prático do Azure.
• Noções básicas de MDC.
• Conhecimento básico de redes.

Pré-requisitos

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

• Ter um circuito ExpressRoute provisionado por meio de um provedor de conectividade.
• Ter uma assinatura do Azure para criar um circuito ExpressRoute e redes virtuais no Azure.
• Ter um roteador que deve:
  • Suporte a conexões VPN site a site entre sua interface LAN e o gateway multilocatário do Azure Stack.
  • Suporte à criação de várias instâncias de roteiros e encaminhamento virtuais se houver mais de um locatário em sua implantação de MDC.
• Tenha um roteador que tenha:
  • Uma porta WAN conectada ao circuito ExpressRoute.
  • Uma porta LAN conectada ao gateway multilocatário do MDC.

Arquitetura de rede ExpressRoute

O diagrama a seguir mostra os ambientes do MDC e do Azure depois que você terminar de configurar o ExpressRoute usando os exemplos deste artigo.