Azure Stack Hub の透過的なプロキシ

透過的なプロキシ (インターセプト、インライン、強制プロキシとも呼ばれます) は、特別なクライアント構成を必要とせずに、ネットワーク層で通常の通信をインターセプトします。 クライアントはプロキシの存在を認識する必要はありません。

データセンターでプロキシを使用するためにすべてのトラフィックが必要な場合は、ネットワーク上のゾーン間でトラフィックを分離することで、ポリシーに従ってすべてのトラフィックを処理するように透過的なプロキシを構成します。

トラフィックの種類

Azure Stack Hub からの送信トラフィックは、テナント トラフィックまたはインフラストラクチャ トラフィックのいずれかに分類されます。

テナント トラフィックは、仮想マシン、ロード バランサー、VPN ゲートウェイ、アプリ サービスなどを使用してテナントによって生成されます。

インフラストラクチャ トラフィックは、ID、パッチと更新プログラム、使用状況メトリック、Marketplace シンジケーション、登録、ログ収集、Windows Defender など、インフラストラクチャ サービスに割り当てられたパブリック仮想 IP プールの最初の /27 範囲から生成されます。これらのサービスからのトラフィックは 、Azure エンドポイントにルーティングされます。 Azure では、プロキシまたは TLS/SSL でインターセプトされたトラフィックによって変更されたトラフィックは受け入れません。 このため、Azure Stack Hub ではネイティブ プロキシ構成がサポートされません。

透過的なプロキシを構成する場合は、すべての送信トラフィックを送信するか、プロキシ経由のインフラストラクチャ トラフィックのみを送信するかを選択できます。

パートナー統合

Microsoft は業界をリードするプロキシ ベンダーと提携し、透過的なプロキシ構成を使用して Azure Stack Hub のユース ケース シナリオを検証しています。 次の図は、HA プロキシを使用した Azure Stack Hub ネットワーク構成の例です。 外部プロキシ デバイスは、境界デバイスの北に配置する必要があります。

境界デバイスの前にプロキシを使用したネットワーク図

さらに、次のいずれかの方法で Azure Stack Hub からのトラフィックをルーティングするように境界デバイスを構成する必要があります。

  • Azure Stack Hub からプロキシ デバイスへのすべての送信トラフィックのルーティング
  • ポリシー ベースのルーティングを使用して、Azure Stack Hub 仮想 IP プールの最初の /27 範囲からプロキシ デバイスにすべての送信トラフィックをルーティングします。

罫線の構成の例については、この記事の 「罫線構成の例 」セクションを参照してください。

Azure Stack Hub で検証済みの透過的なプロキシ構成については、次のドキュメントを確認してください。

Azure Stack Hub からの送信トラフィックが明示的なプロキシ経由で流れる必要があるシナリオでは、Sophos デバイスと Checkpoint デバイスは、透過的モードを介して特定の範囲のトラフィックを許可するデュアルモード機能を提供しますが、他の範囲は明示的モードを通過するように構成できます。 この機能を使用すると、インフラストラクチャ トラフィックのみが透過的プロキシ経由で送信され、すべてのテナント トラフィックが明示的モードで送信されるように、これらのプロキシ デバイスを構成できます。

Von Bedeutung

SSL トラフィックのインターセプトはサポートされていないため、エンドポイントにアクセスするときにサービスエラーが発生する可能性があります。 ID に必要なエンドポイントと通信するためにサポートされる最大タイムアウトは 60 秒で、再試行回数は 3 回です。 詳細については、 Azure Stack Hub ファイアウォールの統合に関するページを参照してください。

罫線の構成の例

このソリューションは、アクセス制御リスト (ACL) によって実装された管理者が定義した一連の条件を使用するポリシー ベースのルーティング (PBR) に基づいています。 ACL は、宛先 IP アドレスのみに基づく通常のルーティングではなく、ルート マップに実装されているプロキシ デバイスの次ホップ IP に送信されるトラフィックを分類します。 ポート 80 および 443 の特定のインフラストラクチャ ネットワーク トラフィックは、境界デバイスから透過的なプロキシ展開にルーティングされます。 透過的なプロキシは URL フィルタリングを行い、 許可されたトラフィックは削除されません 。

次の構成サンプルは、Cisco Nexus 9508 シャーシ用です。

このシナリオでは、インターネットへのアクセスを必要とするソース インフラストラクチャ ネットワークは次のとおりです。

  • パブリック VIP - 最初の/27
  • インフラストラクチャ ネットワーク - 最後の/27
  • BMC ネットワーク - 最後の/27

このシナリオでは、次のサブネットがポリシー ベースのルーティング (PBR) 処理を受け取ります。

ネットワーク IP 範囲 PBR 処理を受けるサブネット
パブリック仮想 IP プール 172.21.107.0/27 の最初の /27 172.21.107.0/27 = 172.21.107.1 から 172.21.107.30
インフラストラクチャ ネットワーク 172.21.7.0/24 の最後の /27 172.21.7.224/27 = 172.21.7.225 から 172.21.7.254
BMC ネットワーク 10.60.32.128/26 の最後の /27 10.60.32.160/27 = 10.60.32.161 から 10.60.32.190

境界デバイスを構成する

feature pbr コマンドを入力して 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
!
!

PBR 処理を受けるトラフィックを識別するために使用される新しい ACL を作成します。 このトラフィックは、この例で詳しく説明するようにプロキシ サービスを取得するテスト ラック内のホスト/サブネットからの Web トラフィック (HTTP ポート 80 と HTTPS ポート 443) です。 たとえば、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>>

PBR 機能のコアは、 TRAFFIC_TO_PROXY_ENV1 ルート マップによって実装されます。 pbr-statistics オプションが追加され、ポリシー一致統計情報を表示して、PBR 転送を行うパケットと取得しないパケットの数を確認できます。 ルート マップ シーケンス 10 は、ACL PERMITTED_TO_PROXY_ENV1 条件を満たすトラフィックに PBR 処理を許可します。 そのトラフィックは、 10.60.3.34 と 10.60.3.35の次ホップ IP アドレスに転送されます。これは、この例の構成のプライマリ/セカンダリ プロキシ デバイスの VIP です。

!
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

ACL は、 TRAFFIC_TO_PROXY_ENV1 ルート マップの一致条件として使用されます。 トラフィックが PERMITTED_TO_PROXY_ENV1 ACL と一致すると、PBR は通常のルーティング テーブルをオーバーライドし、代わりに一覧に示されている IP 次ホップにトラフィックを転送します。

TRAFFIC_TO_PROXY_ENV1 PBR ポリシーは、CL04 ホストとパブリック VIP から、およびテスト ラックの HLH および DVM から境界デバイスに入るトラフィックに適用されます。

次のステップ

ファイアウォール統合の詳細については、 Azure Stack Hub のファイアウォール統合に関するページを参照してください。

  • 最終更新: