Transparante proxy voor Azure Stack Hub

Artikel
07/29/2022
6 minuten om te lezen

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

Als uw datacenter al het verkeer nodig heeft 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 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 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.

Network diagram with proxy before border devices

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 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 routering op basis van beleid.

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 functie met twee modussen waarmee specifieke bereiken van verkeer via de transparante modus worden toegestaan, terwijl andere bereiken kunnen worden geconfigureerd voor het passeren van een expliciete modus. 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

Ssl-verkeersonderschepping wordt niet ondersteund en kan leiden tot servicefouten bij het openen van eindpunten. De maximale ondersteunde time-out om te communiceren met eindpunten die zijn vereist voor identiteit, zijn 60 bij drie 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 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 routetoewijzing, 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 er wordt geen toegestaan verkeer verwijderd.

Het volgende configuratievoorbeeld is voor een Cisco Nexus 9508 Chassis.

In dit scenario zijn de broninfrastructuurnetwerken waarvoor toegang tot internet is vereist, als volgt:

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

De volgende subnetten ontvangen op beleid gebaseerde routeringsbehandeling (PBR) 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 de PBR-behandeling krijgt. Dat verkeer is webverkeer (HTTP-poort 80 en HTTPS-poort 443) van de hosts/subnetten in het testrek dat proxyservice ontvangt, 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 wordt toegevoegd om het weergeven van de statistieken van de beleidsovereenkomst in te schakelen om te controleren welke numerieke pakketten dat wel en niet het doorsturen van PBR doen. Routekaartreeks 10 staat PBR-behandeling toe aan verkeer dat voldoet aan de 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 overeenkomstcriteria voor de TRAFFIC_TO_PROXY_ENV1 routekaart. 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 randapparaat binnenkomt van CL04-hosts en openbare VIP's en van de HLH en DVM in het testrek.

Volgende stappen

Meer informatie over firewallintegratie vindt u in Azure Stack Hub-firewallintegratie.