Proxy transparente para o Azure Stack Hub

Artigo
10/30/2024

Um proxy transparente (também conhecido como interceptação, embutido ou proxy forçado) intercepta a comunicação normal na camada de rede sem a necessidade de 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 em sua 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ário é gerado por locatários por meio de máquinas virtuais, balanceadores de carga, gateways de VPN, serviços de aplicativos etc.

O tráfego de infraestrutura é gerado do primeiro /27 intervalo do pool de IP virtual público atribuído a serviços de infraestrutura, como identidade, patch e atualização, métricas de uso, sindicalização do Marketplace, registro, coleta de logs, Windows Defender etc. O tráfego desses serviços é roteado para pontos de extremidade do Azure. O Azure não aceita o tráfego modificado por um proxy ou tráfego interceptado por TLS/SSL. Esse motivo é o motivo pelo qual o Azure Stack Hub não dá suporte a uma configuração de proxy nativo.

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

Integração de parceiros

A Microsoft fez uma 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 proxies de HA. 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:

Rotear 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 /27 intervalo do pool de IP virtual do Azure Stack Hub para os dispositivos proxy por meio do roteamento baseado em política.

Para obter uma configuração de borda de exemplo, consulte a seção Configuração de borda de exemplo neste artigo.

Examine 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 por meio de um proxy explícito, os dispositivos Sophos e Checkpoint fornecem um recurso de modo duplo que permite intervalos específicos de tráfego por meio 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 somente 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

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. Para obter mais informações, consulte Integração do firewall do Azure Stack Hub.

Exemplo de configuração de borda

A solução baseia-se no PBR (roteamento baseado em política), que usa um conjunto de critérios definido pelo administrador implementado por uma ACL (lista de controle de acesso). A ACL categoriza o tráfego direcionado para o IP do próximo salto dos dispositivos proxy implementados em um mapa de rotas, em vez do roteamento normal baseado apenas no endereço IP de destino. O tráfego de rede de infraestrutura específico para as portas 80 e 443 é roteado dos dispositivos de borda para a implantação de proxy transparente. O proxy transparente faz a filtragem de URL e nenhum tráfego permitido é 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 infraestrutura – Última /27
Rede BMC – Última /27

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

Rede	Intervalo IP	Sub-rede recebendo 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 infraestrutura	Último /27 de 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 a 172.21.7.254
Rede BMC	Último /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 feature pbr comando .

****************************************************************************
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 a nova ACL que será usada para identificar o tráfego que obterá tratamento PBR. Esse tráfego é o tráfego da Web (porta HTTP 80 e a 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 pelo TRAFFIC_TO_PROXY_ENV1 mapa de rotas. A opção pbr-statistics é adicionada para habilitar a exibição das estatísticas de correspondência de política para verificar os pacotes numéricos que fazem e não obtêm encaminhamento PBR. A sequência de mapa de rotas 10 permite que o tratamento de PBR para o tráfego atende aos critérios de PERMITTED_TO_PROXY_ENV1 da ACL. 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 para os dispositivos proxy primários/secundários em 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 rotas 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 de IP listados.

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

Próximas etapas

Saiba mais sobre a integração de firewall em Integração de firewall do Azure Stack Hub.

Compartilhar via