Przezroczysty serwer proxy dla usługi Azure Stack Hub

Przezroczysty serwer proxy (nazywany również przechwytywaniem, wbudowanym lub wymuszonym serwerem proxy) przechwytuje normalną komunikację w warstwie sieciowej bez konieczności specjalnej konfiguracji klienta. Klienci nie muszą mieć świadomości o istnieniu serwera proxy.

Jeśli centrum danych wymaga, aby cały ruch używał serwera proxy, należy skonfigurować przezroczysty serwer proxy do przetwarzania całego ruchu zgodnie z zasadami, oddzielając ruch między strefami w sieci.

Typy ruchu

Ruch wychodzący z usługi Azure Stack Hub jest klasyfikowany jako ruch dzierżawy lub ruch infrastruktury.

Ruch dzierżawy jest generowany przez dzierżawców za pomocą maszyn wirtualnych, modułów równoważenia obciążenia, bram sieci VPN, usług aplikacji itp.

Ruch infrastruktury jest generowany z pierwszego /27 zakresu publicznej puli wirtualnych adresów IP przypisanych do usług infrastruktury, takich jak tożsamość, poprawka i aktualizacja, metryki użycia, syndykacja witryny Marketplace, rejestracja, zbieranie dzienników, usługa Windows Defender itp. Ruch z tych usług jest kierowany do punktów końcowych platformy Azure. Platforma Azure nie akceptuje ruchu zmodyfikowanego przez serwer proxy lub przechwycony ruch TLS/SSL. Dlatego usługa Azure Stack Hub nie obsługuje natywnej konfiguracji serwera proxy.

Podczas konfigurowania przezroczystego serwera proxy można wybrać opcję wysyłania całego ruchu wychodzącego lub tylko ruchu infrastruktury przez serwer proxy.

Integracja z partnerami

Firma Microsoft współpracuje z wiodącymi dostawcami serwerów proxy w branży, aby zweryfikować scenariusze przypadków użycia usługi Azure Stack Hub z przezroczystą konfiguracją serwera proxy. Na poniższym diagramie przedstawiono przykładową konfigurację sieci usługi Azure Stack Hub z serwerami proxy wysokiej dostępności. Urządzenia zewnętrznego serwera proxy muszą być umieszczone na północ od urządzeń przygranicznych.

Ponadto urządzenia obramowania muszą być skonfigurowane do kierowania ruchu z usługi Azure Stack Hub na jeden z następujących sposobów:

• Kierowanie całego ruchu wychodzącego z usługi Azure Stack Hub do urządzeń proxy
• Kierowanie całego ruchu wychodzącego z pierwszego /27 zakresu wirtualnej puli adresów IP usługi Azure Stack Hub do urządzeń proxy za pośrednictwem routingu opartego na zasadach.

Aby uzyskać przykładową konfigurację obramowania, zobacz sekcję Przykład konfiguracji obramowania w tym artykule.

Przejrzyj następujące dokumenty pod kątem zweryfikowanych przezroczystych konfiguracji serwera proxy w usłudze Azure Stack Hub:

• Konfigurowanie przezroczystego serwera proxy bramy zabezpieczeń Check Point
• Konfigurowanie przezroczystego serwera proxy zapory Sophos XG
• Integrowanie usługi Citrix ADC, Citrix Secure Web Gateway z usługą Azure Stack Hub
• Integrowanie urządzenia internetowego Cisco Secure (WSA) z usługą Azure Stack Hub

W scenariuszach, w których ruch wychodzący z usługi Azure Stack Hub jest wymagany do przepływu przez jawny serwer proxy, urządzenia Sophos i Checkpoint zapewniają funkcję trybu podwójnego, która umożliwia korzystanie z określonych zakresów ruchu w trybie przezroczystym, podczas gdy inne zakresy można skonfigurować do przechodzenia przez tryb jawny. Za pomocą tej funkcji te urządzenia proxy można skonfigurować tak, aby tylko ruch infrastruktury był wysyłany przez przezroczysty serwer proxy, podczas gdy cały ruch dzierżawcy jest wysyłany za pośrednictwem trybu jawnego.

Ważne

Przechwytywanie ruchu SSL nie jest obsługiwane i może prowadzić do błędów usługi podczas uzyskiwania dostępu do punktów końcowych. Maksymalny obsługiwany limit czasu komunikacji z punktami końcowymi wymaganymi dla tożsamości to 60-te z 3 próbami ponawiania prób. Aby uzyskać więcej informacji, zobacz Integracja zapory usługi Azure Stack Hub.

Przykładowa konfiguracja obramowania

Rozwiązanie jest oparte na routingu opartym na zasadach (PBR), który używa zdefiniowanego przez administratora zestawu kryteriów implementowanych przez listę kontroli dostępu (ACL). Lista ACL kategoryzuje ruch kierowany do adresu IP następnego przeskoku urządzeń proxy zaimplementowanych w mapie tras, a nie normalnego routingu opartego tylko na docelowym adresie IP. Określony ruch sieciowy infrastruktury dla portów 80 i 443 są kierowane z urządzeń obramowanych do przezroczystego wdrożenia serwera proxy. Przezroczysty serwer proxy filtruje adresy URL i żaden dozwolony ruch nie jest porzucony.

Poniższy przykład konfiguracji dotyczy obudowy Cisco Nexus 9508.

W tym scenariuszu sieci infrastruktury źródłowej, które wymagają dostępu do Internetu, są następujące:

• Publiczny adres VIP — pierwszy /27
• Sieć infrastruktury — ostatnia /27
• Sieć BMC — ostatnia /27

W tym scenariuszu następujące podsieci odbierają leczenie routingu opartego na zasadach (PBR):

Sieć	Zakres adresów IP	Leczenie PBR w podsieci
Publiczna pula wirtualnych adresów IP	Pierwszy /27 z 172.21.107.0/27	172.21.107.0/27 = 172.21.107.1 do 172.21.107.30
Sieć infrastruktury	Ostatnia /27 z 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 do 172.21.7.254
Sieć BMC	Ostatnia /27 z 10.60.32.128/26	10.60.32.160/27 = 10.60.32.161 do 10.60.32.190

Konfigurowanie urządzenia obramowania

Włącz PBR, wprowadzając feature pbr polecenie .

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

Utwórz nową listę ACL, która będzie używana do identyfikowania ruchu, który będzie otrzymywać leczenie PBR. Ten ruch jest ruchem internetowym (port HTTP 80 i HTTPS 443) z hostów/podsieci w stojaku testowym, który pobiera usługę serwera proxy zgodnie z opisem w tym przykładzie. Na przykład nazwa listy ACL jest 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>>

Podstawowe funkcje PBR są implementowane przez TRAFFIC_TO_PROXY_ENV1 mapie tras. Dodano opcję pbr-statistics w celu włączenia wyświetlania statystyk dopasowania zasad w celu zweryfikowania liczby pakietów, które wykonują i nie pobierają przekazywania PBR. Sekwencja mapy tras 10 zezwala na leczenie PBR ruchu spełniającego kryteria PERMITTED_TO_PROXY_ENV1 listy ACL. Ten ruch jest przekazywany do adresów 10.60.3.34 IP następnego przeskoku i 10.60.3.35, które są adresami VIP dla podstawowych/pomocniczych urządzeń proxy w naszej przykładowej konfiguracji

!
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

Listy ACL są używane jako kryteria dopasowania dla TRAFFIC_TO_PROXY_ENV1 mapy tras. Gdy ruch jest zgodny z listą ACL PERMITTED_TO_PROXY_ENV1 , PBR zastępuje normalną tabelę routingu i zamiast tego przekazuje ruch do wymienionych następnego przeskoku adresów IP.

Zasady TRAFFIC_TO_PROXY_ENV1 PBR są stosowane do ruchu, który przechodzi do urządzenia granicznego z hostów CL04 i publicznych adresów VIP oraz z HLH i DVM w stojaku testowym.

Następne kroki

Dowiedz się więcej o integracji zapory, zobacz Integracja zapory usługi Azure Stack Hub.