Transzparens proxy az Azure Stack Hubhoz

  • Cikk

Egy transzparens proxy (más néven elfogó, beágyazott vagy kényszerített proxy) speciális ügyfélkonfiguráció nélkül fogott el normál kommunikációt a hálózati rétegen. Az ügyfeleknek nem kell tudniuk a proxy létezéséről.

Ha az adatközpont megköveteli, hogy az összes forgalom proxyt használjon, úgy konfigurálhat egy transzparens proxyt, hogy az összes forgalmat a szabályzatnak megfelelően dolgozza fel a hálózat zónái közötti forgalom elkülönítésével.

Forgalomtípusok

Az Azure Stack Hubból kimenő forgalom bérlői vagy infrastruktúra-forgalomként van kategorizálva.

A bérlői forgalmat a bérlők virtuális gépek, terheléselosztók, VPN-átjárók, alkalmazásszolgáltatások stb. útján generálják.

Az infrastruktúra-forgalom az infrastruktúra-szolgáltatásokhoz rendelt nyilvános virtuális IP-készlet első /27 tartományából jön létre, például identitás, javítás és frissítés, használati metrikák, Marketplace-szindikáció, regisztráció, naplógyűjtés, Windows Defender stb. Az ezekből a szolgáltatásokból érkező forgalom az Azure-végpontokra lesz irányítva. Az Azure nem fogadja el a proxy vagy a TLS/SSL által lehallgatott forgalom által módosított forgalmat. Ez az oka annak, hogy az Azure Stack Hub nem támogatja a natív proxykonfigurációt.

Transzparens proxy konfigurálásakor dönthet úgy, hogy az összes kimenő forgalmat vagy csak az infrastruktúra forgalmát a proxyn keresztül küldi el.

Partnerintegráció

A Microsoft együttműködött az iparág vezető proxyszállítóival, hogy átlátható proxykonfigurációval érvényesítse az Azure Stack Hub használati esetforgatókönyveit. Az alábbi ábra egy példa az Azure Stack Hub hálózati konfigurációjára ha proxykkal. A külső proxyeszközöket a szegélyeszközöktől északra kell elhelyezni.

Hálózati diagram proxyval a szegélyeszközök előtt

Emellett a szegélyeszközöket úgy kell konfigurálni, hogy az Azure Stack Hubból érkező forgalmat az alábbi módok egyikével irányítsa:

  • Az Összes kimenő forgalom átirányítása az Azure Stack Hubról a proxyeszközökre
  • Az Azure Stack Hub virtuális IP-készlet első /27 tartományából érkező összes kimenő forgalom átirányítása a proxyeszközökre szabályzatalapú útválasztással.

Szegély-mintakonfigurációért lásd a cikk Szegélykonfiguráció példa szakaszát.

Tekintse át a következő dokumentumokat az Azure Stack Hub ellenőrzött transzparens proxykonfigurációihoz:

Olyan esetekben, amikor az Azure Stack Hubból kimenő forgalomra van szükség egy explicit proxyn keresztüli forgalomhoz, a Sophos és a Checkpoint-eszközök kettős módú funkciót biztosítanak, amely lehetővé teszi bizonyos forgalomtartományok transzparens módban történő átvitelét, míg más tartományok konfigurálhatók explicit módon való áthaladásra. Ezzel a funkcióval ezek a proxyeszközök úgy konfigurálhatók, hogy csak az infrastruktúra forgalmát küldi el a transzparens proxyn keresztül, míg az összes bérlői forgalmat explicit módban küldi el a rendszer.

Fontos

Az SSL-forgalom elfogása nem támogatott, és szolgáltatáshibákhoz vezethet a végpontok elérésekor. Az identitáshoz szükséges végpontokkal való kommunikáció maximálisan támogatott időtúllépése 60-at jelent 3 újrapróbálkozási kísérlettel. További információ: Azure Stack Hub tűzfalintegráció.

Példa szegélykonfigurációra

A megoldás a szabályzatalapú útválasztáson (PBR) alapul, amely egy hozzáférés-vezérlési lista (ACL) által implementált rendszergazdai feltételkészletet használ. Az ACL kategorizálja az útvonaltérképen implementált proxyeszközök következő ugrásos IP-címére irányuló forgalmat, nem pedig a normál útválasztást, amely csak a cél IP-címén alapul. A 80-es és 443-es portok adott infrastruktúra-hálózati forgalmát a rendszer a szegélyeszközökről a transzparens proxytelepítésre irányítja. A transzparens proxy elvégzi az URL-szűrést, és egyik engedélyezett forgalom sem lesz elvetve.

A következő konfigurációs minta egy Cisco Nexus 9508 vázhoz készült.

Ebben a forgatókönyvben az internethez hozzáférést igénylő forrásinfrastruktúra-hálózatok a következők:

  • Nyilvános VIP – Első /27
  • Infrastruktúra-hálózat – Utolsó /27
  • BMC-hálózat – Utolsó /27

Ebben a forgatókönyvben a következő alhálózatok kapnak szabályzatalapú útválasztási (PBR-) kezelést:

Network (Hálózat) IP-címtartomány PBR-kezelést fogadó alhálózat
Nyilvános virtuális IP-készlet Első /27/ 172.21.107.0/27 172.21.107.0/27 = 172.21.107.1–172.21.107.30
Infrastruktúra-hálózat Utolsó /27/ 172.21.7.0/24 172.21.7.224/27 = 172.21.7.225–172.21.7.254
BMC-hálózat Utolsó /27/ 10.60.32.128/26 10.60.32.160/27 = 10.60.32.161–10.60.32.190

Szegélyeszköz konfigurálása

Engedélyezze a PBR-t a feature pbr parancs beírásával.

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

Hozza létre az új ACL-t, amely a PBR-kezelést igénylő forgalom azonosítására szolgál. Ez a forgalom webes forgalom (80-as HTTP-port és 443-as HTTPS-port) a tesztállvány gazdagépeiről/alhálózatairól, amelyek a példában ismertetett módon lekéri a proxyszolgáltatást. Az ACL neve például 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>>

A PBR-funkció magját a TRAFFIC_TO_PROXY_ENV1 útvonaltérkép valósítja meg. A pbr-statistics beállítás hozzáadva lehetővé teszi a szabályzategyeztetés statisztikáinak megtekintését a PBR-továbbítást nem igénylő és nem lekéréses csomagok ellenőrzéséhez. A 10-es útvonaltérkép-sorozat engedélyezi az ACL-nek PERMITTED_TO_PROXY_ENV1 feltételeknek megfelelő forgalom PBR-kezelését. Ezt a forgalmat a és következő ugrás ip-címére 10.60.3.3410.60.3.35továbbítja a rendszer, amelyek a példakonfigurációban szereplő elsődleges/másodlagos proxyeszközök IP-címei.

!
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

Az ACL-ek a TRAFFIC_TO_PROXY_ENV1 útvonaltérkép egyeztetési feltételei. Ha a forgalom megfelel a PERMITTED_TO_PROXY_ENV1 ACL-nek, a PBR felülbírálja a normál útválasztási táblát, és ehelyett a következő IP-címekre továbbítja a forgalmat.

A TRAFFIC_TO_PROXY_ENV1 PBR-szabályzatot a rendszer a cl04-gazdagépekről és nyilvános IP-címekről, valamint a hlh-ről és a DVM-ről a tesztállványon lévő határeszközre érkező forgalomra alkalmazza.

Következő lépések

További információ a tűzfalintegrációról: Azure Stack Hub tűzfalintegráció.