Transparentní proxy server pro Azure Stack Hub

Článek
03/22/2025

Transparentní proxy server (označovaný také jako zachycující, lineární nebo vynucený proxy server) přesměrovává běžnou komunikaci na síťové vrstvě bez nutnosti speciální konfigurace klienta. Klienti si nemusí být vědomi existence proxy serveru.

Pokud vaše datacentrum vyžaduje, aby veškerý provoz používal proxy server, nakonfigurujete transparentní proxy pro zpracování veškerého provozu podle zásad oddělením provozu mezi zónami ve vaší síti.

Typy provozu

Odchozí provoz ze služby Azure Stack Hub je kategorizován jako provoz tenanta nebo provoz infrastruktury.

Provoz tenantů generují tenanti prostřednictvím virtuálních počítačů, nástrojů pro vyrovnávání zatížení, bran VPN, aplikačních služeb atd.

Provoz infrastruktury se generuje z prvního /27 rozsahu veřejného fondu IP adres přiřazených ke službám infrastruktury, jako je identita, oprava a aktualizace, metriky využití, syndikace Marketplace, registrace, shromažďování protokolů, Windows Defender atd. Provoz z těchto služeb se směruje do koncových bodů Azure. Azure nepřijímá provoz upravený proxy serverem nebo zachytáným protokolem TLS/SSL. Důvodem je to, že Azure Stack Hub nepodporuje nativní konfiguraci proxy serveru.

Při konfiguraci transparentního proxy serveru se můžete rozhodnout odesílat veškerý odchozí provoz nebo jenom provoz infrastruktury přes proxy server.

Integrace partnerů

Microsoft spolupracuje s předními dodavateli proxy serverů v odvětví, aby ověřil scénáře použití služby Azure Stack Hub s transparentní konfigurací proxy serveru. Následující diagram je příkladem konfigurace sítě služby Azure Stack Hub s proxy servery vysoké dostupnosti. Externí proxy zařízení musí být umístěna na sever od hraničních zařízení.

diagram sítě s proxy serverem před hraničními zařízeními

Hraniční zařízení musí být navíc nakonfigurovaná tak, aby směrovala provoz ze služby Azure Stack Hub jedním z následujících způsobů:

Směrování veškerého odchozího provozu ze služby Azure Stack Hub do proxy zařízení
Směrujte veškerý odchozí provoz z prvního rozsahu /27 z virtuálního fondu IP adres služby Azure Stack Hub do proxy zařízení prostřednictvím směrování podle zásad.

Ukázkovou konfiguraci ohraničení najdete v části Příklad konfigurace ohraničení části tohoto článku.

Projděte si následující dokumenty pro ověřené konfigurace transparentního proxy serveru ve službě Azure Stack Hub:

Ve scénářích, kdy se k průchodu odchozího provozu ze služby Azure Stack Hub vyžaduje explicitní proxy server, zařízení Sophos a Checkpoint poskytují funkci duálního režimu, která umožňuje konkrétní rozsahy provozu prostřednictvím transparentního režimu, zatímco jiné rozsahy je možné nakonfigurovat tak, aby procházely explicitním režimem. Pomocí této funkce je možné tato proxy zařízení nakonfigurovat tak, aby se prostřednictvím transparentního proxy serveru odesílaly jenom přenosy infrastruktury, zatímco veškerý provoz tenanta se odesílá prostřednictvím explicitního režimu.

Důležitý

Zachycování provozu SSL se nepodporuje a může vést k selháním služeb při přístupu ke koncovým bodům. Maximální podporovaný časový limit pro komunikaci s koncovými body vyžadovanými pro identitu je 60 s 3 opakovanými pokusy. Další informace najdete v integraci firewallu Azure Stack Hub.

Příklad konfigurace ohraničení

Řešení je založené na směrování založeném na zásadách (PBR), které používá sadu kritérií definovaných správcem implementovaným seznamem řízení přístupu (ACL). ACL kategorizuje provoz, který je směrován na IP dalšího směrování proxy zařízení implementovaných v mapě směrování, na rozdíl od normálního směrování, které je založeno pouze na cílové IP adrese. Konkrétní provoz síťové infrastruktury pro porty 80 a 443 se směruje z hraničních zařízení do nasazení transparentního proxy serveru. Transparentní proxy server filtruje adresy URL a se neuvolní žádný povolený provoz.

Následující ukázka konfigurace je určená pro skříň Cisco Nexus 9508.

V tomto scénáři jsou sítě zdrojové infrastruktury, které vyžadují přístup k internetu, následující:

Veřejná virtuální IP adresa – první /27
Infrastrukturní síť: poslední /27
Síť BMC – poslední část /27

V tomto scénáři podstupují následující podsítě směrování založené na politikách:

Síť	Rozsah IP adresy	Podsíť, na kterou se aplikuje PBR
Veřejný fond virtuálních IP adres	První /27 z 172.21.107.0/27	172.21.107.0/27 = 172.21.107.1 až 172.21.107.30
Síť infrastruktury	Poslední /27 z 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 až 172.21.7.254
Síť BMC	Poslední /27 z 10.60.32.128/26	10.60.32.160/27 = 10.60.32.161 až 10.60.32.190

Konfigurace hraničního zařízení

Povolte PBR zadáním příkazu feature pbr.

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

Vytvořte nový ACL, který se použije k identifikaci provozu, jenž bude podléhat nakládání podle PBR. Tento webový provoz (HTTP port 80 a HTTPS port 443) pochází z hostitelů a podsítí umístěných v testovacím racku a je přesměrován pomocí proxy služby, jak je podrobně popsáno v tomto příkladu. Například název ACL je 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>>

Jádrem funkcionality PBR je trasová mapa TRAFFIC_TO_PROXY_ENV1. Možnost pbr-statistics je přidána, aby bylo možné zobrazit statistiku shody zásad a ověřit počet paketů, které jsou odesílány s předáváním PBR, a ty, které nejsou. Sekvence mapy trasy 10 umožňuje zpracování PBR provozu, který splňuje kritéria seznamu ACL PERMITTED_TO_PROXY_ENV1. Tento provoz se přesměruje na IP adresy dalšího segmentu směrování 10.60.3.34 a 10.60.3.35, což jsou virtuální IP adresy pro primární/sekundární proxy zařízení v naší ukázkové konfiguraci.

!
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 se používají jako kritéria shody pro TRAFFIC_TO_PROXY_ENV1 trasovou mapu. Když provoz odpovídá seznamu ACL PERMITTED_TO_PROXY_ENV1, PBR přepíše obvyklou směrovací tabulku a přesměruje provoz na uvedené další IP adresy.

Zásady TRAFFIC_TO_PROXY_ENV1 PBR se aplikují na provoz, který vstupuje do hraničního zařízení z hostitelů CL04, veřejných VIP a z HLH a DVM v testovací racku.

Další kroky

Další informace o integraci brány firewall najdete v tématu integrace brány firewall služby Azure Stack Hub.

Sdílet prostřednictvím