Transparante proxy voor Azure Stack Hub

Artikel
03/18/2025

Een transparante proxy (ook wel een onderscheppende, inline of geforceerde proxy genoemd) onderschept normale communicatie op de netwerklaag zonder dat speciale clientconfiguratie nodig is. Clients hoeven zich niet bewust te zijn van het bestaan van de proxy.

Als voor uw datacenter al het verkeer nodig is om een proxy te gebruiken, configureert u een transparante proxy om al het verkeer volgens beleid te verwerken door verkeer tussen de zones in uw netwerk te scheiden.

Verkeerstypen

Uitgaand verkeer van Azure Stack Hub wordt gecategoriseerd als tenantverkeer of infrastructuurverkeer.

Tenantverkeer wordt gegenereerd door tenants via virtuele machines, load balancers, VPN-gateways, app-services, enzovoort.

Infrastructuurverkeer wordt gegenereerd vanaf het eerste /27 bereik van de openbare virtuele IP-adresgroep die is toegewezen aan infrastructuurservices zoals identiteit, patch en update, metrische gegevens over gebruik, Marketplace-syndicatie, registratie, logboekverzameling, Windows Defender, enzovoort. Het verkeer van deze services wordt doorgestuurd naar Azure-eindpunten. Azure accepteert geen verkeer dat is gewijzigd door een proxy of met TLS/SSL onderschept verkeer. Daarom biedt Azure Stack Hub geen ondersteuning voor een systeemeigen proxyconfiguratie.

Wanneer u een transparante proxy configureert, kunt u ervoor kiezen om al het uitgaande verkeer of alleen infrastructuurverkeer via de proxy te verzenden.

Partnerintegratie

Microsoft werkt samen met toonaangevende proxyleveranciers in de branche om de use-casescenario's van Azure Stack Hub te valideren met een transparante proxyconfiguratie. Het volgende diagram is een voorbeeld van een Azure Stack Hub-netwerkconfiguratie met HA-proxy's. Externe proxyapparaten moeten ten noorden van de randapparaten worden geplaatst.

netwerkdiagram met proxy vóór randapparaten

Daarnaast moeten de randapparaten op een van de volgende manieren worden geconfigureerd om verkeer van Azure Stack Hub te routeren:

Al het uitgaande verkeer van Azure Stack Hub routeren naar de proxyapparaten
Routeer al het uitgaande verkeer van het eerste /27-bereik van de virtuele IP-pool van Azure Stack Hub naar de proxyapparaten via beleid-gebaseerde routering.

Zie sectie Voorbeeld van randconfiguratie in dit artikel voor een voorbeeld van een randconfiguratie.

Bekijk de volgende documenten voor gevalideerde transparante proxyconfiguraties met Azure Stack Hub:

In scenario's waarin uitgaand verkeer van Azure Stack Hub nodig is om door een expliciete proxy te stromen, bieden Sophos- en Checkpoint-apparaten een functie met dubbele modus waarmee specifieke bereiken van verkeer via transparante modus kunnen worden uitgevoerd, terwijl andere bereiken kunnen worden geconfigureerd om een expliciete modus door te geven. Met deze functie kunnen deze proxyapparaten zodanig worden geconfigureerd dat alleen infrastructuurverkeer wordt verzonden via de transparante proxy, terwijl al het tenantverkeer wordt verzonden via de expliciete modus.

Belangrijk

Het onderscheppen van SSL-verkeer is niet mogelijk en kan leiden tot servicefouten bij toegang tot eindpunten. De maximaal ondersteunde time-out voor communicatie met eindpunten die vereist zijn voor identiteit is 60 met drie nieuwe pogingen. Zie Azure Stack Hub-firewallintegratievoor meer informatie.

Voorbeeld van randconfiguratie

De oplossing is gebaseerd op op beleid gebaseerde routering (PBR) die gebruikmaakt van een door een beheerder gedefinieerde set criteria die zijn geïmplementeerd door een ACL (Access Control List). De ACL categoriseert het verkeer dat wordt omgeleid naar het volgende hop-IP-adres van de proxyapparaten die zijn geïmplementeerd in een routekaart, in plaats van normale routering die alleen is gebaseerd op het doel-IP-adres. Specifiek netwerkverkeer voor infrastructuur voor poorten 80 en 443 wordt gerouteerd van de randapparaten naar de transparante proxy-implementatie. De transparante proxy filtert URL's en geen verkeer is toegestaan verkeer wordt verwijderd.

Het volgende configuratievoorbeeld is voor een Cisco Nexus 9508 Chassis.

In dit scenario zijn de broninfrastructuurnetwerken die toegang tot internet vereisen als volgt:

Publiek VIP - Eerste /27
Infrastructuurnetwerk - Laatste /27
BMC Network - Laatste /27

In dit scenario ontvangen de volgende subnetten een pbR-behandeling (op beleid gebaseerde routering):

Netwerk	IP-bereik	Subnet met PBR-behandeling
Openbare virtuele IP-adresgroep	Eerste /27 van 172.21.107.0/27	172.21.107.0/27 = 172.21.107.1 tot 172.21.107.30
Infrastructuurnetwerk	Laatste /27 van 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 tot 172.21.7.254
BMC-netwerk	Laatste /27 van 10.60.32.128/26	10.60.32.160/27 = 10.60.32.161 tot 10.60.32.190

Randapparaat configureren

Schakel PBR in door de opdracht feature pbr in te voeren.

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

Maak de nieuwe ACL die wordt gebruikt om verkeer te identificeren dat PBR-behandeling krijgt. Dat verkeer is webverkeer (HTTP-poort 80 en HTTPS-poort 443) van de hosts/subnetten in het testrek dat via een proxyservice verloopt, zoals beschreven in dit voorbeeld. De ACL-naam is bijvoorbeeld 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>>

De kern van de PBR-functionaliteit wordt geïmplementeerd door de TRAFFIC_TO_PROXY_ENV1 routekaart. De optie pbr-statistics wordt toegevoegd om het bekijken van de beleidsmatches statistieken in te schakelen en zo het aantal pakketten te controleren die wel of geen PBR-doorsturen krijgen. Routekaartreeks 10 staat PBR-behandeling toe voor verkeer dat voldoet aan ACL-PERMITTED_TO_PROXY_ENV1 criteria. Dat verkeer wordt doorgestuurd naar de volgende hop-IP-adressen van 10.60.3.34 en 10.60.3.35, de VIP's voor de primaire/secundaire proxyapparaten in onze voorbeeldconfiguratie

!
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

ACLs worden gebruikt als matchcriteria voor de TRAFFIC_TO_PROXY_ENV1 route map. Wanneer verkeer overeenkomt met de PERMITTED_TO_PROXY_ENV1 ACL, overschrijft PBR de normale routeringstabel en stuurt in plaats daarvan het verkeer door naar de vermelde IP-volgende hops.

Het TRAFFIC_TO_PROXY_ENV1 PBR-beleid wordt toegepast op verkeer dat het grensapparaat binnenkomt van CL04-hosts en publieke VIP's en van de HLH en DVM in het testrek.

Volgende stappen

Zie Azure Stack Hub-firewallintegratievoor meer informatie over firewallintegratie.

Delen via