Transparante proxy voor Azure Stack Hub

Artikel
10/30/2024

Een transparante proxy (ook wel een onderscheppings-, inline- of geforceerde proxy genoemd) onderschept normale communicatie op de netwerklaag zonder speciale clientconfiguratie. Clients hoeven niet op de hoogte te zijn van het bestaan van de proxy.

Als uw datacenter vereist dat al het verkeer een proxy gebruikt, 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 op basis van het eerste /27 bereik van de openbare virtuele IP-pool 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 onderschept TLS/SSL-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 het 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 grensapparaten worden geplaatst.

Netwerkdiagram met proxy vóór randapparaten

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

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

Zie de 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 is vereist om door een expliciete proxy te stromen, bieden Sophos- en Checkpoint-apparaten een dual-mode-functie waarmee specifieke verkeersbereiken via de transparante modus kunnen worden uitgevoerd, terwijl andere bereiken kunnen worden geconfigureerd om via een expliciete modus door te gaan. Met deze functie kunnen deze proxyapparaten zodanig worden geconfigureerd dat alleen infrastructuurverkeer wordt verzonden via de transparante proxy, terwijl al het tenantverkeer via de expliciete modus wordt verzonden.

Belangrijk

Onderschepping van SSL-verkeer wordt niet ondersteund en kan leiden tot servicefouten bij het openen van eindpunten. De maximaal ondersteunde time-out voor communicatie met eindpunten die vereist zijn voor identiteit is 60s met 3 nieuwe pogingen. Zie Azure Stack Hub-firewallintegratie voor meer informatie.

Voorbeeld van randconfiguratie

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

Openbaar VIP - Eerste /27
Infrastructuurnetwerk - laatste /27
BMC Network - Laatste /27

De volgende subnetten ontvangen een PBR-behandeling (op beleid gebaseerde routering) in dit scenario:

Netwerk	IP-bereik	Subnet dat PBR-behandeling ontvangt
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 feature pbr opdracht 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 waarmee de proxyservice wordt opgehaald, zoals beschreven in dit voorbeeld. De naam van de ACL 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 is toegevoegd om het weergeven van de beleidsovereenkomststatistieken mogelijk te maken om het aantal pakketten te controleren dat WEL en niet PBR-doorstuurt. Routekaartvolgorde 10 maakt PBR-behandeling mogelijk voor verkeer dat voldoet aan ACL-PERMITTED_TO_PROXY_ENV1 criteria. Dat verkeer wordt doorgestuurd naar de IP-adressen van de volgende hop van 10.60.3.34 en 10.60.3.35. Dit zijn 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

ACL's worden gebruikt als de criteria voor de overeenkomst voor de TRAFFIC_TO_PROXY_ENV1 routetoewijzing. 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-hops.

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

Volgende stappen

Zie Azure Stack Hub-firewallintegratie voor meer informatie over firewallintegratie.

Delen via