Proxy transparente para Azure Stack Hub

Un proxy transparente (también conocido como proxy interceptante, insertado o forzado) intercepta la comunicación normal en el nivel de red sin necesidad de una configuración de cliente especial. Los clientes no necesitan tener en cuenta la existencia del proxy.

Si el centro de datos requiere que todo el tráfico use un proxy, configure un proxy transparente para procesar todo el tráfico según la directiva separando el tráfico entre las zonas de la red.

Tipos de tráfico

El tráfico saliente de Azure Stack Hub se clasifica como tráfico de inquilinos o tráfico de infraestructura.

Los inquilinos generan el tráfico de inquilinos mediante máquinas virtuales, equilibradores de carga, puertas de enlace de VPN, servicios de aplicaciones, etc.

El tráfico de infraestructura se genera a partir del primer intervalo del grupo /27 de direcciones IP virtuales públicas asignado a servicios de infraestructura, como identidad, revisión y actualización, métricas de uso, distribución de Marketplace, registro, recopilación de registros, Windows Defender, etc. El tráfico de estos servicios se enruta a los puntos de conexión de Azure. Azure no acepta el tráfico modificado por un proxy o tráfico interceptado TLS/SSL. Este motivo es el motivo por el que Azure Stack Hub no admite una configuración de proxy nativa.

Al configurar un proxy transparente, puede optar por enviar todo el tráfico saliente o solo el tráfico de infraestructura a través del proxy.

Integración de socios

Microsoft se ha asociado con los principales proveedores de proxy del sector para validar los escenarios de casos de uso de Azure Stack Hub con una configuración de proxy transparente. El diagrama siguiente es un ejemplo de configuración de red de Azure Stack Hub con servidores proxy de alta disponibilidad. Los dispositivos proxy externos deben colocarse al norte de los dispositivos de borde.

Además, los dispositivos de borde deben configurarse para enrutar el tráfico desde Azure Stack Hub de una de las maneras siguientes:

• Enrutar todo el tráfico saliente de Azure Stack Hub a los dispositivos proxy
• Enrutar todo el tráfico saliente desde el primer intervalo del grupo /27 de direcciones IP virtuales de Azure Stack Hub a los dispositivos proxy a través del enrutamiento basado en directivas.

Para obtener una configuración de borde de ejemplo, consulte la sección Configuración de borde de ejemplo de este artículo.

Revise los siguientes documentos para ver las configuraciones de proxy transparente validadas con Azure Stack Hub:

• Configuración de un proxy transparente de Check Point Security Gateway
• Configuración de un proxy transparente del firewall de Sophos XG
• Integración de Citrix ADC, Citrix Secure Web Gateway con Azure Stack Hub
• Integración de Cisco Secure Web Appliance (WSA) con Azure Stack Hub

En escenarios en los que se requiere tráfico saliente de Azure Stack Hub para fluir a través de un proxy explícito, los dispositivos Sophos y Checkpoint proporcionan una característica de modo dual que permite intervalos específicos de tráfico a través del modo transparente, mientras que otros intervalos se pueden configurar para pasar a través de un modo explícito. Con esta característica, estos dispositivos proxy se pueden configurar de forma que solo se envíe tráfico de infraestructura a través del proxy transparente, mientras que todo el tráfico del inquilino se envía a través del modo explícito.

Configuración de borde de ejemplo

La solución se basa en el enrutamiento basado en directivas (PBR) que usa un conjunto definido por el administrador de criterios implementados por una lista de control de acceso (ACL). La ACL clasifica el tráfico que se dirige a la dirección IP del próximo salto de los dispositivos proxy implementados en un mapa de rutas, en lugar de un enrutamiento normal basado solo en la dirección IP de destino. El tráfico de red de infraestructura específico para los puertos 80 y 443 se enrutan desde los dispositivos de borde a la implementación de proxy transparente. El proxy transparente realiza el filtrado de direcciones URL y no se quita el tráfico permitido .

El siguiente ejemplo de configuración es para un chasis Cisco Nexus 9508.

En este escenario, las redes de infraestructura de origen que requieren acceso a Internet son las siguientes:

• VIP pública: primera /27
• Red de infraestructura: última /27
• Red BMC: última /27

Las subredes siguientes reciben tratamiento de enrutamiento basado en directivas (PBR) en este escenario:

Configuración del dispositivo de borde

Para habilitar PBR, escriba el 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
!
!

Cree la nueva ACL que se usará para identificar el tráfico que obtendrá el tratamiento de PBR. Ese tráfico es tráfico web (puerto HTTP 80 y puerto HTTPS 443) de los hosts o subredes del bastidor de prueba que obtiene el servicio proxy, tal como se detalla en este ejemplo. Por ejemplo, el nombre de la ACL es 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>>

El TRAFFIC_TO_PROXY_ENV1 mapa de rutas implementa el núcleo de la funcionalidad de PBR. La opción pbr-statistics se agrega para habilitar la visualización de las estadísticas de coincidencia de directiva para comprobar el número de paquetes que sí y no obtienen el reenvío de PBR. La secuencia de mapa de ruta 10 permite el tratamiento pbr al tráfico que cumple los criterios de PERMITTED_TO_PROXY_ENV1 de ACL. Ese tráfico se reenvía a las direcciones IP del próximo salto de 10.60.3.34 y 10.60.3.35, que son las DIRECCIONES VIP de los dispositivos proxy principal o secundario en nuestra configuración de ejemplo.

!
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

Las ACL se usan como criterios de coincidencia para la TRAFFIC_TO_PROXY_ENV1 mapa de rutas. Cuando el tráfico coincide con la ACL de PERMITTED_TO_PROXY_ENV1 , PBR invalida la tabla de enrutamiento normal y, en su lugar, reenvía el tráfico a los próximos saltos ip enumerados.

La directiva de PBR de TRAFFIC_TO_PROXY_ENV1 se aplica al tráfico que entra en el dispositivo de borde desde hosts CL04 y VIP públicas y desde HLH y DVM en el bastidor de pruebas.

Pasos siguientes

Para más información sobre la integración del firewall, consulte Integración del firewall de Azure Stack Hub.