Transparent proxy för Azure Stack Hub

  • Artikel

En transparent proxy (kallas även för avlyssning, infogad eller framtvingad proxy) fångar upp normal kommunikation i nätverksskiktet utan att det krävs någon särskild klientkonfiguration. Klienterna behöver inte vara medvetna om proxyns existens.

Om ditt datacenter kräver att all trafik använder en proxy konfigurerar du en transparent proxy för att bearbeta all trafik enligt principen genom att separera trafiken mellan zonerna i nätverket.

Trafiktyper

Utgående trafik från Azure Stack Hub kategoriseras som antingen klienttrafik eller infrastrukturtrafik.

Klienttrafik genereras av klienter via virtuella datorer, lastbalanserare, VPN-gatewayer, apptjänster osv.

Infrastrukturtrafik genereras från det första /27 intervallet i den offentliga virtuella IP-poolen som tilldelats infrastrukturtjänster som identitet, korrigering och uppdatering, användningsstatistik, Marketplace-syndikering, registrering, logginsamling, Windows Defender osv. Trafiken från dessa tjänster dirigeras till Azure-slutpunkter. Azure accepterar inte trafik som ändras av en proxy eller TLS/SSL-avlyssnad trafik. Det här är anledningen till att Azure Stack Hub inte stöder en inbyggd proxykonfiguration.

När du konfigurerar en transparent proxy kan du välja att skicka all utgående trafik eller endast infrastrukturtrafik via proxyn.

Partnerintegration

Microsoft samarbetar med ledande proxyleverantörer i branschen för att verifiera Användningsfall för Azure Stack Hub med en transparent proxykonfiguration. Följande diagram är ett exempel på en Azure Stack Hub-nätverkskonfiguration med HA-proxyservrar. Externa proxyenheter måste placeras norr om gränsenheterna.

Nätverksdiagram med proxy före kantlinjeenheter

Dessutom måste gränsenheterna konfigureras för att dirigera trafik från Azure Stack Hub på något av följande sätt:

  • Dirigera all utgående trafik från Azure Stack Hub till proxyenheterna
  • Dirigera all utgående trafik från det första /27 intervallet i den virtuella IP-poolen i Azure Stack Hub till proxyenheterna via principbaserad routning.

Ett exempel på en kantlinjekonfiguration finns i avsnittet Exempel på kantlinjekonfiguration i den här artikeln.

Granska följande dokument för verifierade transparenta proxykonfigurationer med Azure Stack Hub:

I scenarier där utgående trafik från Azure Stack Hub krävs för att flöda genom en explicit proxy, tillhandahåller Sophos- och Checkpoint-enheter en funktion med dubbla lägen som tillåter specifika trafikintervall via transparent läge, medan andra intervall kan konfigureras för att passera genom ett explicit läge. Med den här funktionen kan dessa proxyenheter konfigureras så att endast infrastrukturtrafik skickas via den transparenta proxyn, medan all klienttrafik skickas via explicit läge.

Viktigt

SSL-trafikavlyssning stöds inte och kan leda till tjänstfel vid åtkomst till slutpunkter. Den maximala tidsgräns som stöds för att kommunicera med slutpunkter som krävs för identitet är 60-talet med 3 återförsök. Mer information finns i Brandväggsintegrering för Azure Stack Hub.

Exempel på kantlinjekonfiguration

Lösningen baseras på principbaserad routning (PBR) som använder en administratörsdefinierad uppsättning kriterier som implementeras av en åtkomstkontrollista (ACL). ACL:en kategoriserar trafiken som dirigeras till nästa hopp-IP-adressen för proxyenheterna som implementeras i en routningskarta, i stället för normal routning som endast baseras på målets IP-adress. Specifik infrastrukturnätverkstrafik för portarna 80 och 443 dirigeras från gränsenheterna till den transparenta proxydistributionen. Den transparenta proxyn utför URL-filtrering och ingen tillåten trafik tas bort.

Följande konfigurationsexempel är för ett Cisco Nexus 9508-chassi.

I det här scenariot är de källinfrastrukturnätverk som kräver åtkomst till Internet följande:

  • Offentlig VIP – första /27
  • Infrastrukturnätverk – senaste /27
  • BMC-nätverk – senaste /27

Följande undernät får principbaserad routning (PBR) i det här scenariot:

Nätverk IP-intervall Undernät som får PBR-behandling
Offentlig virtuell IP-pool Första /27 av 172.21.107.0/27 172.21.107.0/27 = 172.21.107.1 till 172.21.107.30
Infrastrukturnätverk Senaste /27 av 172.21.7.0/24 172.21.7.224/27 = 172.21.7.225 till 172.21.7.254
BMC-nätverk Senaste /27 av 10.60.32.128/26 10.60.32.160/27 = 10.60.32.161 till 10.60.32.190

Konfigurera kantlinjeenhet

Aktivera PBR genom att feature pbr ange kommandot .

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

Skapa den nya ACL som ska användas för att identifiera trafik som ska få PBR-behandling. Trafiken är webbtrafik (HTTP-port 80 och HTTPS-port 443) från värdarna/undernäten i testrack som hämtar proxytjänsten enligt beskrivningen i det här exemplet. Till exempel är ACL-namnet 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>>

Kärnan i PBR-funktionen implementeras av TRAFFIC_TO_PROXY_ENV1 route-map. Alternativet pbr-statistics läggs till för att aktivera visning av principmatchningsstatistik för att verifiera antalet paket som utför och inte får PBR-vidarebefordring. Routningskartsekvens 10 tillåter PBR-behandling för trafik som uppfyller ACL-PERMITTED_TO_PROXY_ENV1 kriterier. Trafiken vidarebefordras till nästa hopp-IP-adresserna 10.60.3.34 för och 10.60.3.35, som är VIP för de primära/sekundära proxyenheterna i vår exempelkonfiguration

!
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:er används som matchningsvillkor för TRAFFIC_TO_PROXY_ENV1 routningskarta. När trafiken matchar PERMITTED_TO_PROXY_ENV1 ACL åsidosätter PBR den normala routningstabellen och vidarebefordrar i stället trafiken till den angivna IP-adressen nästa hopp.

Principen TRAFFIC_TO_PROXY_ENV1 PBR tillämpas på trafik som kommer in i gränsenheten från CL04-värdar och offentliga VIP-adresser och från HLH och DVM i testrack.

Nästa steg

Läs mer om brandväggsintegrering i Azure Stack Hub-brandväggsintegrering.