Прозрачный прокси-сервер для Azure Stack Hub

Прозрачный прокси-сервер (также известный как перехват, встроенный или принудительный прокси-сервер) перехватывает обычный обмен данными на сетевом уровне, не требуя специальной конфигурации клиента. Клиентам не нужно знать о существовании прокси-сервера.

Если для центра обработки данных требуется весь трафик для использования прокси-сервера, настройте прозрачный прокси-сервер для обработки всего трафика в соответствии с политикой, разделив трафик между зонами в сети.

Типы трафика

Исходящий трафик из Azure Stack Hub классифицируется как трафик клиента или трафик инфраструктуры.

Трафик клиента создается клиентами путем виртуальных машин, подсистем балансировки нагрузки, VPN-шлюзов, служб приложений и т. д.

Трафик инфраструктуры создается из первого /27 диапазона общедоступного виртуального IP-пула, назначенного службам инфраструктуры, таким как идентификация, исправления и обновления, метрики использования, синдикация Маркетплейс, регистрация, сбор журналов, Защитник Windows и т. д. Трафик из этих служб направляется к конечным точкам Azure. Azure не принимает трафик, измененный прокси-сервером, или трафик, перехваченный посредством протоколов TLS/SSL. Поэтому Azure Stack Hub не поддерживает собственную конфигурацию прокси-сервера.

При настройке прозрачного прокси-сервера можно отправить весь исходящий трафик или только трафик инфраструктуры через прокси-сервер.

Интеграция партнеров

Корпорация Майкрософт сотрудничала с ведущими поставщиками прокси-серверов в отрасли для проверки сценариев использования Azure Stack Hub с прозрачной конфигурацией прокси-сервера. На следующей схеме приведен пример конфигурации сети Azure Stack Hub с прокси-серверами высокого уровня доступности. Внешние прокси-устройства должны размещаться к северу от пограничных устройств.

Кроме того, пограничные устройства должны быть настроены для маршрутизации трафика из Azure Stack Hub одним из следующих способов:

• Маршрутизация всего исходящего трафика из Azure Stack Hub на прокси-устройства
• Перенаправите весь исходящий трафик из первого диапазона /27 виртуального IP-пула Azure Stack Hub на прокси-устройства через маршрутизацию на основе политик.

Пример конфигурации границы см. в разделе Пример конфигурации границы в этой статье.

Ознакомьтесь со следующими документами для проверенных прозрачных конфигураций прокси-сервера с помощью Azure Stack Hub:

• Настройка прозрачного прокси-сервера безопасности шлюза Check Point
• Настройка прокси-прозрачного брандмауэра Sophos XG
• интегрировать Citrix ADC, Citrix Secure Web Gateway с Azure Stack Hub
• Интеграция безопасного веб-устройства Cisco (WSA) с Azure Stack Hub

В сценариях, когда исходящий трафик из Azure Stack Hub должен проходить через явный прокси-сервер, устройства Sophos и Checkpoint предоставляют функцию двойного режима, которая позволяет определённым диапазонам трафика проходить в прозрачном режиме, в то время как другие диапазоны можно настроить для прохождения в явном режиме. С помощью этой функции эти прокси-устройства можно настроить таким образом, чтобы через прозрачный прокси-сервер отправляется только трафик инфраструктуры, а весь трафик клиента отправляется через явный режим.

Важный

Перехват трафика SSL не поддерживается и может привести к сбоям служб при доступе к конечным точкам. Максимальный поддерживаемый тайм-аут для обмена данными с конечными точками, необходимыми для удостоверения личности, составляет 60 секунд при 3 попытках повторной отправки. Дополнительные сведения см. в интеграции брандмауэра с Azure Stack Hub.

Пример конфигурации границы

Решение основано на маршрутизации на основе политик (PBR), которая использует определенный администратором набор критериев, реализованных списком управления доступом (ACL). ACL классифицирует трафик, направленный на IP-адрес следующего прыжка прокси-устройств, реализованных на карте маршрутов, а не обычную маршрутизацию, основанную только на целевом IP-адресе. Сетевой трафик определенной инфраструктуры для портов 80 и 443 направляется от пограничных устройств к прозрачному прокси-серверу. Прозрачный прокси-сервер выполняет фильтрацию URL-адресов и не допускается трафик удаляется.

Следующий пример конфигурации предназначен для шасси Cisco Nexus 9508.

В этом сценарии исходные сети инфраструктуры, требующие доступа к Интернету, приведены ниже.

• Публичный VIP-адрес — первый /27
• Сеть инфраструктуры — последняя /27
• Сеть BMC — последнее /27

Следующие подсети получают обработку маршрутизации на основе политик (PBR) в этом сценарии:

Сеть	Диапазон IP-адресов	Подсеть, получающая обработку PBR
Общедоступный виртуальный IP-пул	Первый /27 из 172.21.107.0/27	172.21.107.0/27 = 172.21.107.1 до 172.21.107.30
Сеть инфраструктуры	Последнее /27 из 172.21.7.0/24	172.21.7.224/27 = 172.21.7.225 до 172.21.7.254
Сеть BMC	Последнее /27 из 10.60.32.128/26	10.60.32.160/27 = 10.60.32.161 до 10.60.32.190

Настройка пограничного устройства

Включите PBR, введя команду feature 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
!
!

Создайте новый ACL, который будет использоваться для идентификации трафика, который получит обработку PBR. Этот трафик представляет собой веб-трафик (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 разрешает обработку PBR для трафика, удовлетворяющего критериям ACL PERMITTED_TO_PROXY_ENV1. Этот трафик пересылается на IP-адреса следующего узла 10.60.3.34 и 10.60.3.35, которые являются виртуальными IP-адресами для первичных и вторичных прокси-устройств в нашем примере конфигурации.

!
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

Списки управления доступом используются в качестве критериев соответствия для маршрутизационной карты TRAFFIC_TO_PROXY_ENV1. Когда трафик соответствует PERMITTED_TO_PROXY_ENV1 ACL, PBR переопределяет обычную таблицу маршрутизации и вместо этого направляет трафик на указанные IP-адреса следующего шага.

Политика PBR TRAFFIC_TO_PROXY_ENV1 применяется к трафику, который поступает в пограничное устройство с узлов CL04 и публичных виртуальных IP-адресов, а также из HLH и DVM в тестовой стойке.

Дальнейшие действия

Дополнительные сведения об интеграции брандмауэра см. в разделе «Интеграция брандмауэра Azure Stack Hub».