Proxy transparente para o Azure Stack Hub

Artigo
03/20/2025

Um proxy transparente (também conhecido como proxy de intercetação, embutido ou forçado) interceta a comunicação normal na camada de rede sem exigir configuração especial do cliente. Os clientes não precisam estar cientes da existência do proxy.

Se o datacenter exigir que todo o tráfego use um proxy, configure um proxy transparente para processar todo o tráfego de acordo com a política, separando o tráfego entre as zonas da rede.

Tipos de tráfego

O tráfego de saída do Azure Stack Hub é categorizado como tráfego de locatário ou tráfego de infraestrutura.

O tráfego de locatários é gerado pelos locatários por meio de máquinas virtuais, balanceadores de carga, gateways VPN, serviços de aplicativos, etc.

O tráfego de infraestrutura é gerado a partir da primeira gama de /27 do pool de IP virtual público atribuído a serviços de infraestrutura, como identidade, patch e atualização, métricas de uso, sincronização do Marketplace, registo, recolha de logs, Windows Defender, etc. O tráfego desses serviços é encaminhado para pontos de extremidade do Azure . O Azure não aceita tráfego modificado por um proxy ou tráfego intercetado por TLS/SSL. Esse motivo é o motivo pelo qual o Azure Stack Hub não oferece suporte a uma configuração de proxy nativa.

Ao configurar um proxy transparente, você pode optar por enviar todo o tráfego de saída ou apenas o tráfego de infraestrutura através do proxy.

Integração de parceiros

A Microsoft fez parceria com os principais fornecedores de proxy do setor para validar os cenários de caso de uso do Azure Stack Hub com uma configuração de proxy transparente. O diagrama a seguir é um exemplo de configuração de rede do Azure Stack Hub com HA Proxies. Os dispositivos proxy externos devem ser colocados ao norte dos dispositivos de borda.

diagrama de rede com proxy antes de dispositivos de borda

Além disso, os dispositivos de borda devem ser configurados para rotear o tráfego do Azure Stack Hub de uma das seguintes maneiras:

Encaminhar todo o tráfego de saída do Azure Stack Hub para os dispositivos proxy
Encaminhe todo o tráfego de saída do primeiro intervalo de /27 do pool de IP virtual do Hub de Azure Stack para os dispositivos proxy por meio do roteamento com base em políticas.

Para ver um exemplo de configuração de borda, consulte a secção Exemplos de configuração de borda neste artigo.

Analise os seguintes documentos para obter configurações de proxy transparentes validadas com o Azure Stack Hub:

Em cenários em que o tráfego de saída do Azure Stack Hub é necessário para fluir através de um proxy explícito, os dispositivos Sophos e Checkpoint fornecem um recurso de modo duplo que permite intervalos específicos de tráfego através do modo transparente, enquanto outros intervalos podem ser configurados para passar por um modo explícito. Usando esse recurso, esses dispositivos proxy podem ser configurados de modo que apenas o tráfego de infraestrutura seja enviado por meio do proxy transparente, enquanto todo o tráfego de locatário é enviado pelo modo explícito.

Importante

A interceptação de tráfego SSL não é suportada e pode levar a falhas de serviço ao aceder a endpoints. O tempo limite máximo suportado para comunicar com endpoints necessários para a identidade é de 60s com 3 tentativas de reenvio. Para obter mais informações, consulte integração de firewall do Azure Stack Hub.

Exemplo de configuração de borda

A solução é baseada em roteamento baseado em políticas (PBR), que usa um conjunto definido pelo administrador de critérios implementados por uma lista de controle de acesso (ACL). A ACL categoriza o tráfego direcionado para o IP do próximo salto dos dispositivos proxy implementados em um mapa de rota, em vez do roteamento normal baseado apenas no endereço IP de destino. O tráfego de rede de infraestrutura específica para as portas 80 e 443 é roteado dos dispositivos de borda para a implantação de proxy transparente. O proxy transparente faz filtragem de URL e, nenhum permitido tráfego é descartado.

O exemplo de configuração a seguir é para um chassi Cisco Nexus 9508.

Nesse cenário, as redes de infraestrutura de origem que exigem acesso à Internet são as seguintes:

VIP Público - Primeira /27
Rede de infraestruturas - Última /27
BMC Network - Última /27

As seguintes sub-redes recebem tratamento de roteamento baseado em política (PBR) nesse cenário:

Rede	Intervalo IP	Sub-rede que está a receber tratamento PBR
Pool de IP virtual público	Primeiro /27 de 172.21.107.0/27	172.21.107.0/27 = 172.21.107.1 a 172.21.107.30
Rede de infraestruturas	Última /27 de 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 a 172.21.7.254
Rede BMC	Última /27 de 10.60.32.128/26	10.60.32.160/27 = 10.60.32.161 a 10.60.32.190

Configurar dispositivo de borda

Habilite o PBR inserindo o comando feature pbr.

****************************************************************************
PBR Configuration for Cisco Nexus 9508 Chassis
PBR Enivronment configured to use VRF08
The test rack has is a 4-node Azure Stack stamp with 2x TOR switches and 1x BMC switch. Each TOR switch 
has a single uplink to the Nexus 9508 chassis using BGP for routing. In this example the test rack 
is in it's own VRF (VRF08)
****************************************************************************
!
feature pbr
!

<Create VLANs that the proxy devices will use for inside and outside connectivity>

!
VLAN 801
name PBR_Proxy_VRF08_Inside
VLAN 802
name PBR_Proxy_VRF08_Outside
!
interface vlan 801
description PBR_Proxy_VRF08_Inside
no shutdown
mtu 9216
vrf member VRF08
no ip redirects
ip address 10.60.3.1/29
!
interface vlan 802
description PBR_Proxy_VRF08_Outside
no shutdown
mtu 9216
vrf member VRF08
no ip redirects
ip address 10.60.3.33/28
!
!
ip access-list PERMITTED_TO_PROXY_ENV1
100 permit tcp 172.21.107.0/27 any eq www
110 permit tcp 172.21.107.0/27 any eq 443
120 permit tcp 172.21.7.224/27 any eq www
130 permit tcp 172.21.7.224/27 any eq 443
140 permit tcp 10.60.32.160/27 any eq www
150 permit tcp 10.60.32.160/27 any eq 443
!
!
route-map TRAFFIC_TO_PROXY_ENV1 pbr-statistics
route-map TRAFFIC_TO_PROXY_ENV1 permit 10
  match ip address PERMITTED_TO_PROXY_ENV1
  set ip next-hop 10.60.3.34 10.60.3.35
!
!
interface Ethernet1/1
  description DownLink to TOR-1:TeGig1/0/47
  mtu 9100
  logging event port link-status
  vrf member VRF08
  ip address 192.168.32.193/30
  ip policy route-map TRAFFIC_TO_PROXY_ENV1
  no shutdown
!
interface Ethernet2/1
  description DownLink to TOR-2:TeGig1/0/48
  mtu 9100
  logging event port link-status
  vrf member VRF08
  ip address 192.168.32.205/30
  ip policy route-map TRAFFIC_TO_PROXY_ENV1
  no shutdown
!

<Interface configuration for inside/outside connections to proxy devices. In this example there are 2 firewalls>

!
interface Ethernet1/41
  description management interface for Firewall-1
  switchport
  switchport access vlan 801
  no shutdown
!
interface Ethernet1/42
  description Proxy interface for Firewall-1
  switchport
  switchport access vlan 802
  no shutdown
!
interface Ethernet2/41
  description management interface for Firewall-2
  switchport
  switchport access vlan 801
  no shutdown
!
interface Ethernet2/42
  description Proxy interface for Firewall-2
  switchport
  switchport access vlan 802
  no shutdown
!

<BGP network statements for VLAN 801-802 subnets and neighbor statements for R023171A-TOR-1/R023171A-TOR-2> 

!
router bgp 65000
!
vrf VRF08
address-family ipv4 unicast
network 10.60.3.0/29
network 10.60.3.32/28
!
neighbor 192.168.32.194
  remote-as 65001
  description LinkTo 65001:R023171A-TOR-1:TeGig1/0/47
  address-family ipv4 unicast
    maximum-prefix 12000 warning-only
neighbor 192.168.32.206
  remote-as 65001
  description LinkTo 65001:R023171A-TOR-2:TeGig1/0/48
  address-family ipv4 unicast
    maximum-prefix 12000 warning-only
!
!

Crie o novo ACL que será usado para identificar o tráfego que receberá tratamento PBR. Esse tráfego é tráfego da Web (porta HTTP 80 e porta HTTPS 443) dos hosts/sub-redes no rack de teste que obtém o serviço de proxy, conforme detalhado neste exemplo. Por exemplo, o nome da ACL é PERMITTED_TO_PROXY_ENV1.

ip access-list PERMITTED_TO_PROXY_ENV1
100 permit tcp 172.21.107.0/27 any eq www <<HTTP traffic from CL04 Public Admin VIPs leaving test rack>>
110 permit tcp 172.21.107.0/27 any eq 443 <<HTTPS traffic from CL04 Public Admin VIPs leaving test rack>>
120 permit tcp 172.21.7.224/27 any eq www <<HTTP traffic from CL04 INF-pub-adm leaving test rack>>
130 permit tcp 172.21.7.224/27 any eq 443 <<HTTPS traffic from CL04 INF-pub-adm leaving test rack>>
140 permit tcp 10.60.32.160/27 any eq www <<HTTP traffic from DVM and HLH leaving test rack>>
150 permit tcp 10.60.32.160/27 any eq 443 <<HTTPS traffic from DVM and HLH leaving test rack>>

O núcleo da funcionalidade PBR é implementado através do route-map TRAFFIC_TO_PROXY_ENV1. A opção pbr-statistics é adicionada para permitir a visualização das estatísticas de correspondência de política e verificar o número de pacotes que são encaminhados ou não via PBR. A sequência 10 do route-map permite o tratamento PBR para o tráfego que cumpre com os critérios da ACL PERMITTED_TO_PROXY_ENV1. Esse tráfego é encaminhado para os endereços IP do próximo salto de 10.60.3.34 e 10.60.3.35, que são os VIPs dos dispositivos proxy primários/secundários na nossa configuração de exemplo.

!
route-map TRAFFIC_TO_PROXY_ENV1 pbr-statistics
route-map TRAFFIC_TO_PROXY_ENV1 permit 10
  match ip address PERMITTED_TO_PROXY_ENV1
  set ip next-hop 10.60.3.34 10.60.3.35

As ACLs são usadas como critérios de correspondência para o mapa de rota TRAFFIC_TO_PROXY_ENV1. Quando o tráfego corresponde à ACL PERMITTED_TO_PROXY_ENV1, o PBR substitui a tabela de roteamento normal e, em vez disso, encaminha o tráfego para os próximos saltos IP listados.

A política TRAFFIC_TO_PROXY_ENV1 PBR é aplicada ao tráfego que entra no dispositivo de borda, proveniente dos hosts CL04, dos VIPs públicos, bem como do HLH e do DVM no rack de teste.

Próximos passos

Saiba mais sobre a integração de firewall no Azure Stack Hub, veja .

Partilhar via