Transparenter Proxy für Azure Stack Hub

Ein transparenter Proxy (auch als Abfangen, Inline oder erzwungener Proxy bezeichnet) fängt die normale Kommunikation auf der Netzwerkebene ab, ohne dass eine spezielle Clientkonfiguration erforderlich ist. Clients müssen nicht wissen, dass der Proxy vorhanden ist.

Wenn Ihr Rechenzentrum den gesamten Datenverkehr für die Verwendung eines Proxys benötigt, konfigurieren Sie einen transparenten Proxy, um den gesamten Datenverkehr gemäß der Richtlinie zu verarbeiten, indem Sie den Datenverkehr zwischen den Zonen in Ihrem Netzwerk trennen.

Datenverkehrstypen

Ausgehender Datenverkehr aus Azure Stack Hub wird entweder als Mandantendatenverkehr oder Infrastrukturdatenverkehr kategorisiert.

Der Mandantendatenverkehr wird von Mandanten über virtuelle Computer, Lastenausgleichsgeräte, VPN-Gateways, App-Dienste usw. generiert.

Infrastrukturdatenverkehr wird aus dem ersten /27 Bereich des öffentlichen virtuellen IP-Pools generiert, der Infrastrukturdiensten wie Identität, Patch und Update, Nutzungsmetriken, Marketplace-Syndication, Registrierung, Protokollsammlung, Windows Defender usw. zugewiesen ist. Der Datenverkehr von diesen Diensten wird an Azure-Endpunkte weitergeleitet. Azure akzeptiert keinen Datenverkehr, der von einem Proxy oder TLS/SSL abgefangenen Datenverkehr geändert wurde. Aus diesem Grund unterstützt Azure Stack Hub keine systemeigene Proxykonfiguration.

Beim Konfigurieren eines transparenten Proxys können Sie auswählen, dass der gesamte ausgehende Datenverkehr oder nur der Infrastrukturdatenverkehr über den Proxy gesendet werden soll.

Partner-Integration

Microsoft hat sich mit führenden Proxyanbietern in der Branche zusammengetan, um die Anwendungsfallszenarien von Azure Stack Hub mit einer transparenten Proxykonfiguration zu überprüfen. Das folgende Diagramm ist ein Beispiel für eine Azure Stack Hub-Netzwerkkonfiguration mit HA-Proxys. Externe Proxygeräte müssen nördlich der Rahmengeräte platziert werden.

Darüber hinaus müssen die Rahmengeräte so konfiguriert werden, dass der Datenverkehr von Azure Stack Hub auf eine der folgenden Arten weitergeleitet wird:

• Weiterleiten des gesamten ausgehenden Datenverkehrs von Azure Stack Hub an die Proxygeräte
• Leiten Sie den gesamten ausgehenden Datenverkehr aus dem ersten /27 Bereich des virtuellen Azure Stack Hub-IP-Pools über richtlinienbasiertes Routing an die Proxygeräte weiter.

Eine Beispielrahmenkonfiguration finden Sie im Abschnitt " Beispielrahmenkonfiguration " in diesem Artikel.

Überprüfen Sie die folgenden Dokumente für überprüfte transparente Proxykonfigurationen mit Azure Stack Hub:

• Konfigurieren eines transparenten Proxys für das Check Point Security Gateway
• Konfigurieren eines transparenten Sophos XG-Firewallproxys
• Integrieren von Citrix ADC, Citrix Secure Web Gateway in Azure Stack Hub
• Integrieren von Cisco Secure Web Appliance (WSA) in Azure Stack Hub

In Szenarien, in denen ausgehender Datenverkehr vom Azure Stack Hub erforderlich ist, um einen expliziten Proxy zu durchlaufen, bieten Sophos- und Checkpoint-Geräte ein Dual-Mode-Feature, das bestimmte Datenverkehrsbereiche über den transparenten Modus zulässt, während andere Bereiche so konfiguriert werden können, dass sie über einen expliziten Modus geleitet werden. Mithilfe dieses Features können diese Proxygeräte so konfiguriert werden, dass nur Infrastrukturdatenverkehr über den transparenten Proxy gesendet wird, während der gesamte Mandantendatenverkehr über den expliziten Modus gesendet wird.

Beispiel für die Rahmenkonfiguration

Die Lösung basiert auf richtlinienbasiertem Routing (PBR), das einen von einem Administrator definierten Satz von Kriterien verwendet, die von einer Zugriffssteuerungsliste (Access Control List, ACL) implementiert werden. Die ACL kategorisiert den Datenverkehr, der an die nächste Hop-IP der Proxygeräte weitergeleitet wird, die in einer Routenzuordnung implementiert sind, anstatt normales Routing, das nur auf der Ziel-IP-Adresse basiert. Spezifischer Infrastrukturnetzwerkdatenverkehr für ports 80 und 443 werden von den Rahmengeräten an die transparente Proxybereitstellung weitergeleitet. Der transparente Proxy führt die URL-Filterung durch, und kein zulässiger Datenverkehr wird gelöscht.

Das folgende Konfigurationsbeispiel ist für ein Cisco Nexus 9508 Chassis.

In diesem Szenario sind die Quellinfrastrukturnetzwerke, die Zugriff auf das Internet erfordern, wie folgt:

• Öffentliche VIP - First /27
• Infrastrukturnetzwerk – Letzte /27
• BMC-Netzwerk - Letzte /27

Die folgenden Subnetze erhalten in diesem Szenario eine richtlinienbasierte Routingbehandlung (PBR):

Konfigurieren des Rahmengeräts

Aktivieren Sie PBR, indem Sie den feature pbr Befehl eingeben.

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

Erstellen Sie die neue ACL, die verwendet wird, um Datenverkehr zu identifizieren, der PBR-Behandlung erhält. Dieser Datenverkehr ist Webdatenverkehr (HTTP-Port 80 und HTTPS-Port 443) von den Hosts/Subnetzen im Testgestell, der den Proxydienst wie in diesem Beispiel beschrieben abruft. Beispielsweise ist der ACL-Name 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>>

Der Kern der PBR-Funktionalität wird durch die TRAFFIC_TO_PROXY_ENV1 Routenkarte implementiert. Die Pbr-Statistics-Option wird hinzugefügt, um das Anzeigen der Statistiken zur Richtlinienüberstimmung zu ermöglichen, um die Anzahl der Pakete zu überprüfen, die die PBR-Weiterleitung nicht erhalten. Route-Map Sequence 10 ermöglicht die PBR-Behandlung für den Datenverkehr, der PERMITTED_TO_PROXY_ENV1 Kriterien erfüllt. Dieser Datenverkehr wird an die IP-Adressen 10.60.3.34 des nächsten Hops weitergeleitet, 10.60.3.35bei denen es sich um die VIPs für die primären/sekundären Proxygeräte in unserer Beispielkonfiguration handelt.

!
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

ACLs werden als Übereinstimmungskriterien für die TRAFFIC_TO_PROXY_ENV1 Routenkarte verwendet. Wenn datenverkehr mit dem PERMITTED_TO_PROXY_ENV1 ACL übereinstimmt, überschreibt PBR die normale Routingtabelle und leitet stattdessen den Datenverkehr an die aufgelisteten IP-Nächsten-Hops weiter.

Die TRAFFIC_TO_PROXY_ENV1 PBR-Richtlinie wird auf Datenverkehr angewendet, der das Grenzgerät von CL04-Hosts und öffentlichen VIPs und vom HLH und DVM im Testgestell eingibt.

Nächste Schritte

Weitere Informationen zur Firewallintegration finden Sie unter Azure Stack Hub-Firewallintegration.