Transparentní proxy server pro Azure Stack Hub

Článek
03/29/2024

Transparentní proxy server (označovaný také jako zachytávání, vložený nebo vynucený proxy server) zachycuje normální komunikaci na síťové vrstvě bez nutnosti speciální konfigurace klienta. Klienti nemusí o existenci proxy serveru vědět.

Pokud vaše datacentrum vyžaduje, aby veškerý provoz používal proxy server, nakonfigurujete transparentní proxy server tak, aby zpracovával veškerý provoz 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 přenosy dat tenanta nebo infrastruktury.

Přenosy 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 fondu veřejných virtuálních IP adres přiřazeného ke službám infrastruktury, jako jsou identity, patch and update, 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 provoz zachycený protokolem TLS/SSL. Z tohoto důvodu Azure Stack Hub nepodporuje nativní konfiguraci proxy serveru.

Při konfiguraci transparentního proxy serveru můžete zvolit odesílání veškerého odchozího provozu nebo pouze provozu infrastruktury prostřednictvím proxy serveru.

Integrace partnerských řešení

Microsoft spolupracuje s předními dodavateli proxy serveru v oboru, aby ověřil scénáře použití služby Azure Stack Hub s transparentní konfigurací proxy serveru. Následující diagram znázorňuje ukázkovou konfiguraci sítě služby Azure Stack Hub s proxy servery vysoké dostupnosti. Externí proxy zařízení musí být umístěná 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 /27 rozsahu fondu virtuálních IP adres služby Azure Stack Hub do proxy zařízení prostřednictvím směrování založeného na zásadách.

Ukázkovou konfiguraci ohraničení najdete v části Ukázková konfigurace ohraničení v tomto článku.

Projděte si následující dokumenty o ověřených konfiguracích transparentního proxy serveru se službou Azure Stack Hub:

Ve scénářích, kdy se vyžaduje, aby odchozí provoz ze služby Azure Stack Hub procházel explicitním proxy serverem, poskytují zařízení Sophos a Kontrolní body funkci duálního režimu, která umožňuje konkrétní rozsahy provozu v transparentním 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 transparentním proxy serverem odesílaly pouze přenosy infrastruktury, zatímco veškerý provoz tenanta se odesílají přes explicitní režim.

Důležité

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

Příklad konfigurace ohraničení

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

Následující ukázka konfigurace je určena 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
Síť infrastruktury – Poslední /27
Síť řadiče pro správu základní desky – poslední /27

Následující podsítě obdrží v tomto scénáři ošetření směrováním na základě zásad:

Síť	Rozsah IP adres	Podsíť, která přijímá léčbu PBR
Fond veřejných 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íť řadiče pro správu základní desky	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í

Zadáním příkazu povolte PBR 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ý seznam ACL, který se použije k identifikaci provozu, který bude léčen PBR. Tento provoz je webový provoz (port HTTP 80 a port HTTPS 443) z hostitelů nebo podsítí v testovacím racku, který získává službu proxy, jak je podrobně popsáno v tomto příkladu. Například název seznamu 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ádro funkce PBR implementuje TRAFFIC_TO_PROXY_ENV1 route-map. Přidá se možnost pbr-statistics , která umožňuje zobrazení statistiky shody zásad za účelem ověření počtu paketů, které mají a které nedostanou předávání PBR. Sekvence mapy trasy 10 umožňuje zpracování PBR na provoz splňující kritéria PERMITTED_TO_PROXY_ENV1 ACL. Tento provoz se přesměruje na IP adresy dalšího segmentu směrování a 10.60.3.3410.60.3.35, což jsou virtuální IP adresy primárních a sekundárních 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

Seznamy ACL se používají jako kritéria shody pro TRAFFIC_TO_PROXY_ENV1 route-map. Když provoz odpovídá seznamu ACL PERMITTED_TO_PROXY_ENV1 , PBR přepíše normální směrovací tabulku a místo toho předá provoz na uvedené další směrování IP adres.

Zásady TRAFFIC_TO_PROXY_ENV1 PBR se použijí na provoz, který vstupuje do hraničního zařízení z hostitelů CL04 a veřejných virtuálních ip adres a z HLH a DVM v testovacím stojanu.

Další kroky

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