Proxy transparent pour Azure Stack Hub

Un proxy transparent (également appelé interceptage, inline ou proxy forcé) intercepte les communications normales au niveau de la couche réseau sans nécessiter de configuration de client spéciale. Les clients n’ont pas besoin de connaître l’existence du proxy.

Si votre centre de données exige que tout le trafic utilise un proxy, vous configurez un proxy transparent pour traiter tout le trafic en fonction de la stratégie en séparant le trafic entre les zones de votre réseau.

Types de trafic

Le trafic sortant d’Azure Stack Hub est classé en tant que trafic client ou trafic d’infrastructure.

Le trafic de locataire est généré par des locataires par le biais de machines virtuelles, d’équilibreurs de charge, de passerelles VPN, de services d’application, etc.

Le trafic d’infrastructure est généré à partir de la première /27 plage du pool d’adresses IP virtuelles publiques affectées aux services d’infrastructure tels que l’identité, le correctif et la mise à jour, les métriques d’utilisation, la syndication de la Place de marché, l’inscription, la collecte de journaux, Windows Defender, etc. Le trafic de ces services est acheminé vers les points de terminaison Azure. Azure n’accepte pas le trafic modifié par un proxy ou un trafic intercepté TLS/SSL. C’est pourquoi Azure Stack Hub ne prend pas en charge une configuration de proxy native.

Lors de la configuration d’un proxy transparent, vous pouvez choisir d’envoyer tout le trafic sortant ou uniquement le trafic d’infrastructure via le proxy.

Intégration du partenaire

Microsoft a collaboré avec les principaux fournisseurs de proxy du secteur pour valider les scénarios de cas d’usage d’Azure Stack Hub avec une configuration de proxy transparente. Le diagramme suivant est un exemple de configuration réseau Azure Stack Hub avec des proxys haute disponibilité. Les appareils proxy externes doivent être placés au nord des appareils frontaliers.

En outre, les appareils de bordure doivent être configurés pour acheminer le trafic à partir d’Azure Stack Hub de l’une des manières suivantes :

• Acheminer tout le trafic sortant d’Azure Stack Hub vers les appareils proxy
• Routez tout le trafic sortant de la première /27 plage du pool d’adresses IP virtuelles Azure Stack Hub vers les appareils proxy via le routage basé sur la stratégie.

Pour obtenir un exemple de configuration de bordure, consultez la section Exemple de configuration de bordure dans cet article.

Passez en revue les documents suivants pour connaître les configurations de proxy transparentes validées avec Azure Stack Hub :

• Configurer un proxy transparent de la passerelle de sécurité Check Point
• Configurer un proxy transparent de pare-feu Sophos XG
• Intégrer Citrix ADC, Citrix Secure Web Gateway à Azure Stack Hub
• Intégrer Cisco Secure Web Appliance (WSA) à Azure Stack Hub

Dans les scénarios où le trafic sortant d’Azure Stack Hub est nécessaire pour passer par un proxy explicite, Sophos et les appareils Checkpoint fournissent une fonctionnalité en double mode qui permet des plages spécifiques de trafic via le mode transparent, tandis que d’autres plages peuvent être configurées pour passer par un mode explicite. À l’aide de cette fonctionnalité, ces appareils proxy peuvent être configurés afin que seul le trafic d’infrastructure soit envoyé via le proxy transparent, tandis que tout le trafic client est envoyé via le mode explicite.

Exemple de configuration de bordure

La solution est basée sur le routage basé sur la stratégie (PBR) qui utilise un ensemble de critères défini par l’administrateur implémenté par une liste de contrôle d’accès (ACL). La liste de contrôle d’accès classe le trafic dirigé vers l’adresse IP de tronçon suivant des appareils proxy implémentés dans une carte de routage, plutôt que le routage normal basé uniquement sur l’adresse IP de destination. Le trafic réseau d’infrastructure spécifique pour les ports 80 et 443 est acheminé des appareils frontaliers vers le déploiement transparent du proxy. Le proxy transparent effectue le filtrage d’URL et aucun trafic autorisé n’est supprimé.

L’exemple de configuration suivant concerne un châssis Cisco Nexus 9508.

Dans ce scénario, les réseaux d’infrastructure source qui nécessitent l’accès à Internet sont les suivants :

• Adresse IP virtuelle publique - Premier /27
• Réseau d’infrastructure - Dernière /27
• Réseau BMC - Dernière /27

Les sous-réseaux suivants reçoivent le traitement PBR (Policy-Based Routing) dans ce scénario :

Configurer un appareil de bordure

Activez PBR en entrant la feature pbr commande.

****************************************************************************
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
!
!

Créez la liste de contrôle d’accès qui sera utilisée pour identifier le trafic qui obtiendra un traitement PBR. Ce trafic est le trafic web (port HTTP 80 et port HTTPS 443) à partir des hôtes/sous-réseaux du rack de test qui obtient le service proxy comme indiqué dans cet exemple. Par exemple, le nom de la liste de contrôle d’accès est 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>>

Le cœur de la fonctionnalité PBR est implémenté par la carte de routage TRAFFIC_TO_PROXY_ENV1 . L’option pbr-statistics est ajoutée pour activer l’affichage des statistiques de correspondance de stratégie pour vérifier le nombre de paquets qui effectuent et n’obtiennent pas le transfert PBR. La séquence de carte de routage 10 autorise le traitement PBR au trafic répondant aux critères de PERMITTED_TO_PROXY_ENV1 de liste de contrôle d’accès . Ce trafic est transféré aux adresses IP du tronçon suivant et 10.60.3.3410.60.3.35, qui sont les adresses IP virtuelles des appareils proxy principaux/secondaires dans notre exemple de configuration

!
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

Les listes de contrôle d’accès sont utilisées comme critères de correspondance pour la carte de routage TRAFFIC_TO_PROXY_ENV1 . Lorsque le trafic correspond à la liste de contrôle d’accès PERMITTED_TO_PROXY_ENV1 , PBR remplace la table de routage normale et transfère plutôt le trafic aux tronçons ip suivants répertoriés.

La stratégie PBR TRAFFIC_TO_PROXY_ENV1 est appliquée au trafic qui entre dans l’appareil de bordure à partir des hôtes CL04 et des adresses IP virtuelles publiques et du HLH et de la machine virtuelle DVM dans le rack de test.

Étapes suivantes

En savoir plus sur l’intégration du pare-feu, consultez Intégration du pare-feu Azure Stack Hub.