Integração de rede robusta do Azure Stack Hub
Este tópico aborda a integração de rede do Azure Stack.
Conectividade de borda (uplink)
O planejamento de integração de rede é um pré-requisito importante para implantação, operação e gerenciamento bem-sucedidos de sistemas integrados do Azure Stack. O planejamento de conectividade de borda começa ao escolher se você deseja usar o roteamento dinâmico com o BGP (Border Gateway Protocol). Isso requer atribuir um número de sistema autônomo BGP de 16 bits (público ou privado) ou usar o roteamento estático, em que uma rota padrão estática é atribuída aos dispositivos de borda.
A parte superior dos comutadores tor (rack) exigem uplinks de Camada 3 com IPs ponto a ponto (/30 redes) configurados nas interfaces físicas. Não há suporte para uplinks de camada 2 com comutadores TOR que dão suporte a operações do Azure Stack.
Roteamento BGP
O uso de um protocolo de roteamento dinâmico, como o BGP, garante que seu sistema esteja sempre ciente das alterações de rede e facilita a administração. Para segurança aprimorada, uma senha pode ser definida no emparelhamento via protocolo BGP entre o TOR e a Borda.
Conforme mostrado no diagrama a seguir, a publicidade do espaço IP privado na opção TOR é bloqueada usando uma lista de prefixos. A lista de prefixos nega o anúncio da Rede Privada e é aplicada como um mapa de rotas na conexão entre o TOR e a borda.
O software Load Balancer (SLB) em execução dentro da solução do Azure Stack emparelha os dispositivos TOR para que ele possa anunciar dinamicamente os endereços VIP.
Para garantir que o tráfego do usuário se recupere imediatamente e de forma transparente de falhas, o VPC ou MLAG configurado entre os dispositivos TOR permite o uso de agregação de link de vários chassis para os hosts e HSRP ou VRRP que fornece redundância de rede para as redes IP.
Roteamento estático
O roteamento estático requer configuração adicional para os dispositivos de borda. Ele requer uma intervenção e gerenciamento mais manuais, bem como uma análise completa antes de qualquer alteração. Problemas causados por um erro de configuração podem levar mais tempo para serem revertidos dependendo das alterações feitas. Esse método de roteamento não é recomendado, mas tem suporte.
Para integrar o Azure Stack ao seu ambiente de rede usando o roteamento estático, todos os quatro links físicos entre a borda e o dispositivo TOR devem estar conectados. Não é possível garantir alta disponibilidade devido ao funcionamento do roteamento estático.
O dispositivo de borda deve ser configurado com rotas estáticas apontando para cada um dos quatro IPs P2P definidos entre o TOR e a Borda para o tráfego destinado a qualquer rede dentro do Azure Stack, mas apenas a rede VIP externa ou pública é necessária para a operação. As rotas estáticas para o BMC e as redes externas são necessárias para a implantação inicial. Os operadores podem optar por deixar rotas estáticas na borda para acessar recursos de gerenciamento que residem no BMC e na rede de infraestrutura. Adicionar rotas estáticas às redes de infraestrutura do comutador e gerenciamento do comutador é opcional.
Os dispositivos TOR são configurados com uma rota padrão estática enviando todo o tráfego para os dispositivos de borda. A única exceção de tráfego à regra padrão é para o espaço privado, que é bloqueado usando uma lista de Controle de Acesso aplicada no TOR à conexão de borda.
O roteamento estático aplica-se somente aos uplinks entre o TOR e os comutadores de borda. O roteamento dinâmico BGP é usado dentro do rack porque é uma ferramenta essencial para o SLB e outros componentes e não pode ser desabilitado ou removido.
* A rede BMC é opcional após a implantação.
** A rede Alternar Infraestrutura é opcional, pois toda a rede pode ser incluída na rede de Gerenciamento de Comutadores.
A rede de Gerenciamento de Comutadores é necessária e pode ser adicionada separadamente da rede de Infraestrutura de Comutador.
Proxy transparente
Se o datacenter exigir que todo o tráfego use um proxy, você deverá configurar um proxy transparente para processar todo o tráfego do rack para tratá-lo de acordo com a política, separando o tráfego entre as zonas em sua rede.
A solução do Azure Stack não dá suporte a proxies Web normais
Um proxy transparente (também conhecido como interceptação, embutido ou proxy forçado) intercepta a comunicação normal na camada de rede sem exigir nenhuma configuração especial do cliente. Os clientes não precisam estar cientes da existência do proxy.
Não há suporte para interceptação de tráfego SSL e pode levar a falhas de serviço ao acessar pontos de extremidade. O tempo limite máximo com suporte para se comunicar com os pontos de extremidade necessários para a identidade é de 60s com três tentativas de repetição.
DNS
Esta seção aborda a configuração do DNS (Sistema de Nomes de Domínio).
Configurar o encaminhamento DNS condicional
Isso só se aplica a uma implantação do AD FS.
Para habilitar a resolução de nomes com a infraestrutura DNS existente, configure o encaminhamento condicional.
Para adicionar um encaminhador condicional, você deve usar o ponto de extremidade privilegiado.
Para este procedimento, use um computador em sua rede de datacenter que possa se comunicar com o ponto de extremidade privilegiado no Azure Stack.
Abra uma sessão com privilégios elevados do PowerShell no Windows (execute como administrador) e conecte-se ao endereço IP do ponto de extremidade privilegiado. Use as credenciais para autenticação CloudAdmin.
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred
Depois de se conectar ao ponto de extremidade privilegiado, execute o comando do PowerShell a seguir. Substitua os valores de exemplo fornecidos pelo nome de domínio e endereços IP dos servidores DNS que você deseja usar.
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2"
Resolvendo nomes DNS do Azure Stack de fora do Azure Stack
Os servidores autoritativos são aqueles que têm as informações de zonas DNS externas e as zonas criadas pelo usuário. Integre-se a esses servidores para habilitar a delegação de zona ou o encaminhamento condicional para resolve nomes DNS do Azure Stack de fora do Azure Stack.
Obter informações do ponto de extremidade externo do servidor DNS
Para integrar sua implantação do Azure Stack à sua infraestrutura DNS, você precisa das seguintes informações:
FQDNs do servidor DNS
Endereços IP do servidor DNS
Os FQDNs para os servidores DNS do Azure Stack têm o seguinte formato:
<NAMINGPREFIX-ns01>.<REGIÃO>.<EXTERNALDOMAINNAME>
<NAMINGPREFIX-ns02>.<REGIÃO>.<EXTERNALDOMAINNAME>
Usando os valores de exemplo, os FQDNs dos servidores DNS serão:
azs-ns01.east.cloud.fabrikam.com
azs-ns02.east.cloud.fabrikam.com
Essas informações estão disponíveis no portal de administração, mas também criadas no final de todas as implantações do Azure Stack em um arquivo chamado AzureStackStampInformation.json. Esse arquivo está localizado na pasta C:\CloudDeployment\logs da máquina virtual implantação. Se você não tiver certeza de quais valores foram usados para sua implantação do Azure Stack, poderá obter os valores aqui.
Se a máquina virtual implantação não estiver mais disponível ou estiver inacessível, você poderá obter os valores conectando-se ao ponto de extremidade privilegiado e executando o cmdlet Get-AzureStackStampInformation PowerShell. Para obter mais informações, consulte ponto de extremidade privilegiado.
Configurando o encaminhamento condicional para o Azure Stack
A maneira mais simples e segura de integrar o Azure Stack à sua infraestrutura DNS é fazer o encaminhamento condicional da zona do servidor que hospeda a zona pai. Essa abordagem é recomendada se você tiver controle direto sobre os servidores DNS que hospedam a zona pai para o namespace DNS externo do Azure Stack.
Se você não estiver familiarizado com como fazer o encaminhamento condicional com o DNS, consulte o seguinte artigo do TechNet: Atribuir um encaminhador condicional para um nome de domínio ou a documentação específica para sua solução DNS.
Em cenários em que você especificou sua Zona DNS do Azure Stack externa para parecer um domínio filho do nome de domínio corporativo, o encaminhamento condicional não pode ser usado. A delegação de DNS deve ser configurada.
Exemplo:
Nome de Domínio DNS Corporativo: contoso.com
Nome de domínio DNS externo do Azure Stack: azurestack.contoso.com
Editando IPs de encaminhador DNS
Os IPs encaminhador de DNS são definidos durante a implantação do Azure Stack. No entanto, se os IPs do encaminhador precisarem ser atualizados por qualquer motivo, você poderá editar os valores conectando-se ao ponto de extremidade privilegiado e executando o Get-AzSDnsForwarder e Set-AzSDnsForwarder cmdlets do PowerShell [[-IPAddress] <[]>]. Para obter mais informações, consulte ponto de extremidade privilegiado.
Delegando a zona DNS externa para o Azure Stack
Para que os nomes DNS possam ser resolvidos de fora de uma implantação do Azure Stack, você precisa configurar a delegação de DNS.
Cada registrador tem suas próprias ferramentas de gerenciamento de DNS para alterar os registros de servidor de nomes para um domínio. Na página de gerenciamento de DNS do registrador, edite os registros NS e substitua os registros NS da zona pelos do Azure Stack.
A maioria dos registradores DNS exige que você forneça um mínimo de dois servidores DNS para concluir a delegação.
Firewall
O Azure Stack configura VIPs (endereços IP virtuais) para suas funções de infraestrutura. Esses VIPs são alocados do pool de endereços IP públicos. Cada VIP é protegido com uma ACL (lista de controle de acesso) na camada de rede definida pelo software. As ACLs também são usadas entre os comutadores físicos (TORs e BMC) para proteger ainda mais a solução. Uma entrada DNS é criada para cada ponto de extremidade na zona DNS externa especificada no momento da implantação. Por exemplo, o portal do usuário recebe a entrada de host DNS do portal. <região>.<fqdn>.
O diagrama de arquitetura a seguir mostra as diferentes camadas de rede e ACLs:
Portas e URLs
Para disponibilizar os serviços do Azure Stack (como portais, Azure Resource Manager, DNS e assim por diante) para redes externas, você deve permitir o tráfego de entrada para esses pontos de extremidade para URLs, portas e protocolos específicos.
Em uma implantação em que um proxy transparente é vinculado a um servidor proxy tradicional ou um firewall está protegendo a solução, você deve permitir portas e URLs específicas para comunicação de entrada e saída. Isso inclui portas e URLs para identidade, marketplace, patch e atualização, registro e dados de uso.
Comunicação de saída
O Azure Stack dá suporte apenas a servidores proxy transparentes. Em uma implantação com um uplink de proxy transparente para um servidor proxy tradicional, você deve permitir as portas e URLs na tabela a seguir para comunicação de saída ao implantar no modo conectado.
Não há suporte para interceptação de tráfego SSL e pode levar a falhas de serviço ao acessar pontos de extremidade. O tempo limite máximo com suporte para se comunicar com os pontos de extremidade necessários para a identidade é de 60s.
Observação
O Azure Stack não dá suporte ao uso do ExpressRoute para acessar os serviços do Azure listados na tabela a seguir porque o ExpressRoute pode não ser capaz de rotear o tráfego para todos os pontos de extremidade.
Finalidade | URL de destino | Protocolo | Portas | Rede de origem |
---|---|---|---|---|
Identidade | Azure login.windows.net login.microsoftonline.com graph.windows.net https://secure.aadcdn.microsoftonline-p.com www.office.com ManagementServiceUri = https://management.core.windows.net ARMUri = https://management.azure.com https://*.msftauth.net https://*.msauth.net https://*.msocdn.com Azure Governamental https://login.microsoftonline.us/ https://graph.windows.net/ Azure China 21Vianet https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure Alemanha https://login.microsoftonline.de/ https://graph.cloudapi.de/ |
HTTP HTTPS |
80 443 |
VIP público – /27 Rede de infraestrutura pública |
Sindicalização do Marketplace | Azure https://management.azure.com https://*.blob.core.windows.net https://*.azureedge.net Azure Governamental https://management.usgovcloudapi.net/ https://*.blob.core.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn |
HTTPS | 443 | VIP público – /27 |
Patch & Update | https://*.azureedge.net https://aka.ms/azurestackautomaticupdate |
HTTPS | 443 | VIP público – /27 |
Registro | Azure https://management.azure.com Azure Governamental https://management.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn |
HTTPS | 443 | VIP público – /27 |
Uso | Azure https://*.trafficmanager.net Azure Governamental https://*.usgovtrafficmanager.net Azure China 21Vianet https://*.trafficmanager.cn |
HTTPS | 443 | VIP público – /27 |
Windows Defender | *.wdcp.microsoft.com *.wdcpalt.microsoft.com *.wd.microsoft.com *.update.microsoft.com *.download.microsoft.com https://www.microsoft.com/pkiops/crl https://www.microsoft.com/pkiops/certs https://crl.microsoft.com/pki/crl/products https://www.microsoft.com/pki/certs https://secure.aadcdn.microsoftonline-p.com |
HTTPS | 80 443 |
VIP público – /27 Rede de infraestrutura pública |
NTP | (IP do servidor NTP fornecido para implantação) | UDP | 123 | VIP público – /27 |
DNS | (IP do servidor DNS fornecido para implantação) | TCP UDP |
53 | VIP público – /27 |
CRL | (URL em Pontos de Distribuição de CRL em seu certificado) | HTTP | 80 | VIP público – /27 |
LDAP | Floresta do Active Directory fornecida para integração do Graph | TCP UDP |
389 | VIP público – /27 |
LDAP SSL | Floresta do Active Directory fornecida para integração do Graph | TCP | 636 | VIP público – /27 |
LDAP GC | Floresta do Active Directory fornecida para integração do Graph | TCP | 3268 | VIP público – /27 |
LDAP GC SSL | Floresta do Active Directory fornecida para integração do Graph | TCP | 3269 | VIP público – /27 |
AD FS | Ponto de extremidade de metadados do AD FS fornecido para integração do AD FS | TCP | 443 | VIP público – /27 |
Serviço de coleta de logs de diagnóstico | URL SAS do Blob fornecida pelo Armazenamento do Azure | HTTPS | 443 | VIP público – /27 |
Comunicação de entrada
Um conjunto de VIPs de infraestrutura é necessário para publicar pontos de extremidade do Azure Stack em redes externas. A tabela ponto de extremidade (VIP) mostra cada ponto de extremidade, a porta necessária e o protocolo. Consulte a documentação de implantação do provedor de recursos específica para pontos de extremidade que exigem provedores de recursos adicionais, como o provedor de recursos SQL.
OS VIPs de infraestrutura interna não estão listados porque não são necessários para publicar o Azure Stack. Os VIPs do usuário são dinâmicos e definidos pelos próprios usuários, sem controle pelo operador do Azure Stack
Observação
A VPN IKEv2 é uma solução vpn IPsec baseada em padrões que usa as portas UDP 500 e 4500 e TCP 50. Os firewalls nem sempre abrem essas portas, portanto, uma VPN IKEv2 pode não ser capaz de percorrer proxies e firewalls.
Ponto de extremidade (VIP) | Registro A do host DNS | Protocolo | Portas |
---|---|---|---|
AD FS | Adfs. <região>.<Fqdn> | HTTPS | 443 |
Portal (administrador) | Adminportal. <região>.<Fqdn> | HTTPS | 443 |
Adminhosting | *.adminhosting.<região>.<Fqdn> | HTTPS | 443 |
Resource Manager do Azure (administrador) | Adminmanagement. <região>.<Fqdn> | HTTPS | 443 |
Portal (usuário) | Portal. <região>.<Fqdn> | HTTPS | 443 |
Azure Resource Manager (usuário) | Gestão. <região>.<Fqdn> | HTTPS | 443 |
Grafo | Gráfico. <região>.<Fqdn> | HTTPS | 443 |
Lista de revogação de certificados | Crl.region<.<>Fqdn> | HTTP | 80 |
DNS | *. <região>.<Fqdn> | TCP & UDP | 53 |
Hosting | *.De.<região>.<Fqdn> | HTTPS | 443 |
Key Vault (usuário) | *.Cofre. <região>.<Fqdn> | HTTPS | 443 |
Key Vault (administrador) | *.adminvault. <região>.<Fqdn> | HTTPS | 443 |
Fila de Armazenamento | *.Fila. <região>.<Fqdn> | HTTP HTTPS |
80 443 |
Tabela de Armazenamento | *.Tabela. <região>.<Fqdn> | HTTP HTTPS |
80 443 |
Blob de Armazenamento | *.Blob. <região>.<Fqdn> | HTTP HTTPS |
80 443 |
Provedor de Recursos SQL | sqladapter.dbadapter. <região>.<Fqdn> | HTTPS | 44300-44304 |
Provedor de Recursos do MySQL | mysqladapter.dbadapter. <região>.<Fqdn> | HTTPS | 44300-44304 |
Serviço de Aplicativo | *.appservice. <região>.<Fqdn> | TCP | 80 (HTTP) 443 (HTTPS) 8172 (MSDeploy) |
*.scm.appservice. <região>.<Fqdn> | TCP | 443 (HTTPS) | |
api.appservice. <região>.<Fqdn> | TCP | 443 (HTTPS) 44300 (Azure Resource Manager) |
|
ftp.appservice. <região>.<Fqdn> | TCP, UDP | 21, 1021, 10001-10100 (FTP) 990 (FTPS) |
|
Gateways VPN | Confira as Perguntas frequentes sobre o gateway de VPN. | ||
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de