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

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

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

Типы трафика

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

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

Трафик инфраструктуры формируется из первого /27 диапазона общедоступного пула виртуальных IP-адресов, назначенного службам инфраструктуры, таким как удостоверения, исправления и обновления, метрики использования, синдикация Marketplace, регистрация, сбор журналов, Защитник 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 Secure Web Appliance (WSA) с Azure Stack Hub

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

Важно!

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

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

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

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

В этом сценарии сети исходной инфраструктуры, которым требуется доступ к Интернету, будут следующими:

• Общедоступный ВИРТУАЛЬНЫй IP-адрес — первый /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 схеме маршрутов. Если трафик соответствует списку ACL PERMITTED_TO_PROXY_ENV1 , PBR переопределяет обычную таблицу маршрутизации и вместо этого перенаправляет трафик в указанные IP-прыжки следующего прыжка.

Политика TRAFFIC_TO_PROXY_ENV1 PBR применяется к трафику, который поступает на пограничное устройство с узлов CL04 и общедоступных ВИРТУАЛЬНЫх IP-адресов, а также из HLH и DVM в тестовой стойке.

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

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