Proxy trasparente per l'hub di Azure Stack

Articolo
10/30/2024

Un proxy trasparente (noto anche come proxy di intercettazione, inline o forzato) intercetta le normali comunicazioni a livello di rete senza richiedere una configurazione client speciale. I client non devono essere consapevoli dell'esistenza del proxy.

Se il data center richiede che tutto il traffico usi un proxy, configurare un proxy trasparente per elaborare tutto il traffico in base ai criteri separando il traffico tra le zone della rete.

Tipi di traffico

Il traffico in uscita dall'hub di Azure Stack viene classificato come traffico del tenant o traffico dell'infrastruttura.

Il traffico tenant viene generato dai tenant tramite macchine virtuali, servizi di bilanciamento del carico, gateway VPN, servizi app e così via.

Il traffico dell'infrastruttura viene generato dal primo /27 intervallo del pool ip virtuale pubblico assegnato ai servizi di infrastruttura, ad esempio identità, patch e aggiornamento, metriche di utilizzo, diffusione del Marketplace, registrazione, raccolta log, Windows Defender e così via. Il traffico da questi servizi viene instradato agli endpoint di Azure. Azure non accetta traffico modificato da un proxy o da un traffico intercettato TLS/SSL. Questo è il motivo per cui l'hub di Azure Stack non supporta una configurazione proxy nativa.

Quando si configura un proxy trasparente, è possibile scegliere di inviare tutto il traffico in uscita o solo il traffico dell'infrastruttura attraverso il proxy.

Integrazione dei partner

Microsoft ha collaborato con i principali fornitori di proxy del settore per convalidare gli scenari dei casi d'uso dell'hub di Azure Stack con una configurazione proxy trasparente. Il diagramma seguente è un esempio di configurazione di rete dell'hub di Azure Stack con proxy a disponibilità elevata. I dispositivi proxy esterni devono essere posizionati a nord dei dispositivi border.

Diagramma di rete con proxy prima dei dispositivi border

Inoltre, i dispositivi border devono essere configurati per instradare il traffico dall'hub di Azure Stack in uno dei modi seguenti:

Instradare tutto il traffico in uscita dall'hub di Azure Stack ai dispositivi proxy
Instradare tutto il traffico in uscita dal primo /27 intervallo del pool di indirizzi IP virtuali dell'hub di Azure Stack ai dispositivi proxy tramite il routing basato su criteri.

Per una configurazione del bordo di esempio, vedere la sezione Configurazione del bordo di esempio in questo articolo.

Esaminare i documenti seguenti per le configurazioni del proxy trasparente convalidate con l'hub di Azure Stack:

Negli scenari in cui è necessario il traffico in uscita dall'hub di Azure Stack per passare attraverso un proxy esplicito, i dispositivi Sophos e Checkpoint offrono una funzionalità a doppia modalità che consente intervalli specifici di traffico attraverso la modalità trasparente, mentre altri intervalli possono essere configurati per passare attraverso una modalità esplicita. Usando questa funzionalità, questi dispositivi proxy possono essere configurati in modo che solo il traffico dell'infrastruttura venga inviato tramite il proxy trasparente, mentre tutto il traffico del tenant viene inviato tramite la modalità esplicita.

Importante

L'intercettazione del traffico SSL non è supportata e può causare errori del servizio durante l'accesso agli endpoint. Il timeout massimo supportato per comunicare con gli endpoint necessari per l'identità è 60s con 3 tentativi. Per altre informazioni, vedere Integrazione del firewall dell'hub di Azure Stack.

Configurazione del bordo di esempio

La soluzione si basa sul routing basato su criteri (PBR) che usa un set di criteri definito dall'amministratore implementato da un elenco di controllo di accesso (ACL). L'ACL classifica il traffico indirizzato all'indirizzo IP hop successivo dei dispositivi proxy implementati in una mappa di route, anziché il routing normale basato solo sull'indirizzo IP di destinazione. Il traffico di rete dell'infrastruttura specifico per le porte 80 e 443 viene instradato dai dispositivi border alla distribuzione del proxy trasparente. Il proxy trasparente esegue il filtro url e non viene eliminato alcun traffico consentito .

L'esempio di configurazione seguente è per uno chassis Cisco Nexus 9508.

In questo scenario, le reti dell'infrastruttura di origine che richiedono l'accesso a Internet sono le seguenti:

INDIRIZZO VIP pubblico - Primo /27
Rete dell'infrastruttura - Ultimo /27
Rete BMC - Ultimo /27

In questo scenario le subnet seguenti ricevono il trattamento del routing basato su criteri :The following subnets receive policy-based routing (PBR) in questo scenario:

Rete	Intervallo IP	Trattamento PBR per la ricezione di subnet
Pool ip virtuale pubblico	Primo /27 di 172.21.107.0/27	172.21.107.0/27 = 172.21.107.1 a 172.21.107.30
Rete dell'infrastruttura	Ultimo /27 di 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 a 172.21.7.254
Rete BMC	Ultimo /27 di 10.60.32.128/26	Da 10.60.32.160/27 = 10.60.32.161 a 10.60.32.190

Configurare il dispositivo bordo

Abilitare PBR immettendo il feature pbr comando .

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

Creare il nuovo ACL che verrà usato per identificare il traffico che otterrà il trattamento PBR. Tale traffico è il traffico Web (porta HTTP 80 e porta HTTPS 443) dagli host/subnet nel rack di test che ottiene il servizio proxy come descritto in questo esempio. Ad esempio, il nome ACL è 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>>

Il nucleo della funzionalità PBR viene implementato dalla TRAFFIC_TO_PROXY_ENV1 mappa di route. L'opzione pbr-statistics viene aggiunta per consentire la visualizzazione delle statistiche di corrispondenza dei criteri per verificare i pacchetti numerici che eseguono e non ottengono l'inoltro PBR. La sequenza 10 della mappa di route consente il trattamento PBR per soddisfare i criteri di PERMITTED_TO_PROXY_ENV1 ACL del traffico. Tale traffico viene inoltrato agli indirizzi IP dell'hop successivo di 10.60.3.34 e 10.60.3.35, che sono gli indirizzi VIP per i dispositivi proxy primario/secondario nella configurazione di esempio

!
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

Gli ACL vengono usati come criteri di corrispondenza per il TRAFFIC_TO_PROXY_ENV1 mappa di route. Quando il traffico corrisponde al PERMITTED_TO_PROXY_ENV1 ACL, PBR esegue l'override della normale tabella di routing e inoltra invece il traffico agli hop successivi ip elencati.

Il criterio PBR TRAFFIC_TO_PROXY_ENV1 viene applicato al traffico che entra nel dispositivo border da host CL04 e indirizzi VIP pubblici e da HLH e DVM nel rack di test.

Passaggi successivi

Altre informazioni sull'integrazione del firewall, vedere Integrazione del firewall dell'hub di Azure Stack.

Condividi tramite