Bagikan melalui


Proksi transparan untuk Azure Stack Hub

Proksi transparan (juga dikenal sebagai meng-intersepsi, sejalan, atau proksi yang dipaksa) mencegat komunikasi normal pada lapisan jaringan tanpa memerlukan konfigurasi klien khusus. Klien tidak perlu menyadari keberadaan proksi.

Jika pusat data Anda mengharuskan semua lalu lintas untuk menggunakan proksi, Anda mengonfigurasi proksi transparan untuk memproses semua lalu lintas sesuai kebijakan dengan memisahkan lalu lintas antara zona di jaringan Anda.

Jenis lalu lintas

Lalu lintas keluar dari Azure Stack Hub dikategorikan sebagai lalu lintas penyewa atau lalu lintas infrastruktur.

Lalu lintas penyewa dihasilkan oleh penyewa melalui mesin virtual, penyeimbang beban, gateway VPN, layanan aplikasi, dll.

Lalu lintas infrastruktur dihasilkan dari rentang pertama /27 kumpulan IP virtual publik yang ditugaskan untuk layanan infrastruktur seperti identitas, patch dan pembaruan, metrik penggunaan, sindikasi Marketplace, pendaftaran, pengumpulan log, Windows Defender, dll. Lalu lintas dari layanan ini dialihkan ke titik akhir Azure. Azure tidak menerima lalu lintas yang dimodifikasi oleh lalu lintas yang disadap proksi atau TLS/SSL. Alasan inilah mengapa Azure Stack Hub tidak mendukung konfigurasi proksi asli.

Saat mengonfigurasi proksi transparan, Anda dapat memilih untuk mengirim semua lalu lintas keluar atau hanya lalu lintas infrastruktur melalui proksi.

Integrasi mitra

Microsoft telah bermitra dengan vendor proksi terkemuka di industri untuk memvalidasi skenario kasus penggunaan Azure Stack Hub dengan konfigurasi proxy transparan. Diagram berikut adalah contoh konfigurasi jaringan Azure Stack Hub dengan Proksi high availability. Perangkat proksi eksternal harus ditempatkan di utara perangkat perbatasan.

Diagram jaringan dengan proksi sebelum perangkat batas

Selain itu, perangkat perbatasan harus dikonfigurasi untuk merutekan lalu lintas dari Azure Stack Hub dengan salah satu cara berikut:

  • Merutekan semua lalu lintas keluar dari Azure Stack Hub ke perangkat proksi
  • Rutekan semua lalu lintas keluar dari rentang pertama /27 kumpulan IP virtual Azure Stack Hub ke perangkat proksi melalui perutean berbasis kebijakan.

Untuk konfigurasi batas sampel, lihat bagian Konfigurasi batas contoh di artikel ini.

Tinjau dokumen berikut untuk konfigurasi proksi transparan yang divalidasi dengan Azure Stack Hub:

Dalam skenario di mana lalu lintas keluar dari Azure Stack Hub diperlukan untuk mengalir melalui proksi eksplisit, perangkat Sophos dan Checkpoint menyediakan fitur dual-mode yang memungkinkan rentang lalu lintas tertentu melalui mode transparan, sementara rentang lain dapat dikonfigurasi untuk melewati mode eksplisit. Dengan menggunakan fitur ini, perangkat proksi ini dapat dikonfigurasi sedemikian rupa sehingga hanya lalu lintas infrastruktur yang dikirim melalui proksi transparan, sementara semua lalu lintas penyewa dikirim melalui mode eksplisit.

Penting

Intersepsi lalu lintas SSL tidak didukung dan dapat menyebabkan kegagalan layanan saat mengakses titik akhir. Batas waktu maksimum yang didukung untuk berkomunikasi dengan titik akhir yang diperlukan untuk identitas adalah 60-an dengan 3 upaya coba ulang. Untuk informasi selengkapnya, lihat Integrasi firewall Azure Stack Hub.

Konfigurasi batas contoh

Solusi ini didasarkan pada perutean berbasis kebijakan (PBR) yang menggunakan seperangkat kriteria yang ditentukan administrator yang diimplementasikan oleh daftar kontrol akses (ACL). ACL mengategorikan lalu lintas yang diarahkan ke IP lompatan berikutnya dari perangkat proksi yang diimplementasikan dalam peta rute, bukan perutean normal yang hanya didasarkan pada alamat IP tujuan. Lalu lintas jaringan infrastruktur khusus untuk port 80 dan 443 dialihkan dari perangkat perbatasan ke penyebaran proksi transparan. Proksi transparan melakukan penyaringan URL, dan lalu lintas tidak ada yang diizinkan dijatuhkan.

Sampel konfigurasi berikut adalah untuk Cisco Nexus 9508 Chassis.

Dalam skenario ini, jaringan infrastruktur sumber yang memerlukan akses ke internet adalah sebagai berikut:

  • VIP Publik - /27 Pertama
  • Jaringan infrastruktur - /27 terakhir
  • Jaringan BMC - /27 Terakhir

Subnet berikut menerima perlakuan perutean berbasis kebijakan (PBR) dalam skenario ini:

Jaringan Rentang IP Subnet menerima perawatan PBR
Kumpulan IP Virtual Publik Pertama /27 dari 172.21.107.0/27 172.21.107.0/27 = 172.21.107.1 hingga 172.21.107.30
Jaringan infrastruktur Terakhir /27 dari 172.21.7.0/24 172.21.7.224/27 = 172.21.7.225 hingga 172.21.7.254
Jaringan BMC Terakhir /27 dari 10.60.32.128/26 10.60.32.160/27 = 10.60.32.161 hingga 10.60.32.190

Mengonfigurasi perangkat batas

Aktifkan PBR dengan memasukkan perintah 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
!
!

Buat ACL baru yang akan digunakan untuk mengidentifikasi lalu lintas yang akan mendapatkan perawatan PBR. Lalu lintas itu adalah lalu lintas web (port HTTP 80 dan port HTTPS 443) dari host/subnet di rak pengujian yang mendapat layanan proksi sebagaimana diperinci dalam contoh ini. Misalnya, nama ACL-nya 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>>

Inti dari fungsi PBR diimplementasikan oleh peta rute TRAFFIC_TO_PROXY_ENV1. Opsi pbr-statistics ditambahkan untuk memungkinkan melihat statistik kecocokan kebijakan untuk memverifikasi paket angka yang dilakukan dan tidak mendapatkan penerusan PBR. Urutan peta rute 10 memungkinkan perlakuan PBR untuk memenuhi lalu lintas kriteria PERMITTED_TO_PROXY_ENV1 ACL. Lalu lintas itu diteruskan ke alamat IP lompatan berikutnya 10.60.3.34 dan 10.60.3.35, yang merupakan VIP untuk perangkat proksi primer/sekunder dalam konfigurasi contoh kami

!
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 digunakan sebagai kriteria pencocokan untuk peta rute TRAFFIC_TO_PROXY_ENV1. Ketika lalu lintas cocok dengan ACL PERMITTED_TO_PROXY_ENV1, PBR menimpa tabel perutean normal, dan sebagai gantinya meneruskan lalu lintas ke IP lompatan berikutnya yang terdaftar.

Kebijakan PBR TRAFFIC_TO_PROXY_ENV1 diterapkan pada lalu lintas yang memasuki perangkat perbatasan dari host CL04 dan VIP publik dan dari HLH dan DVM di rak uji.

Langkah berikutnya

Pelajari integrasi firewall selengkapnya, lihat Integrasi firewall Azure Stack Hub.