Прозрачный прокси-сервер для 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 и Checkpoint предоставляют функцию двойного режима, которая позволяет определенным диапазонам трафика через прозрачный режим, а другие диапазоны можно настроить для передачи через явный режим. С помощью этой функции эти прокси-устройства можно настроить таким образом, чтобы через прозрачный прокси-сервер отправлялся только трафик инфраструктуры, а весь трафик клиента отправляется через явный режим.

Важно!

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

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

Решение основано на маршрутизации на основе политик (PBR), которая использует определенный администратором набор критериев, реализованных списком управления доступом (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-адрес следующим прыжкам.

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

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

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