Menyebarkan instans Azure API Management Anda ke jaringan virtual - mode eksternal

  • Artikel

BERLAKU UNTUK: Pengembang | Premium

Azure API Management dapat disebarkan (disuntikkan) di dalam jaringan virtual Azure (VNet) untuk mengakses layanan backend dalam jaringan. Untuk opsi, persyaratan, dan pertimbangan konektivitas VNet, lihat:

Artikel ini menjelaskan cara menyiapkan konektivitas VNet untuk instans API Management Anda dalam mode eksternal, di mana portal pengembang, gateway API, dan titik akhir API Management lainnya dapat diakses dari internet publik, dan layanan backend terletak di dalam jaringan.

Membuat sambungan ke VNET eksternal

Untuk konfigurasi khusus untuk mode internal , di mana titik akhir hanya dapat diakses dalam VNet, lihat Menyebarkan instans Azure API Management Anda ke jaringan virtual - mode internal.

Catatan

Sebaiknya Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Lihat Menginstal Azure PowerShell untuk memulai. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Prasyarat

Tinjau persyaratan sumber daya jaringan untuk injeksi API Management ke jaringan virtual sebelum Anda mulai.

Beberapa prasyarat berbeda tergantung pada versi (stv2 atau stv1) dari platform komputasi hosting instans API Management Anda.

Tip

Ketika Anda menggunakan portal untuk membuat atau memperbarui koneksi jaringan instans API Management yang ada, instans tersebut dihosting di platform komputasi stv2.

  • Jaringan virtual dan subnet harus berada di wilayah dan langganan yang sama dengan instans API Management Anda.

    • Subnet yang digunakan untuk tersambung ke instans API Management mungkin berisi jenis sumber daya Azure lainnya.
    • Subnet tidak boleh mengaktifkan delegasi apa pun. Delegasikan subnet ke pengaturan layanan untuk subnet harus diatur ke Tidak Ada.

  • Kelompok keamanan jaringan yang dilampirkan ke subnet di atas. Kelompok keamanan jaringan (NSG) diperlukan untuk mengizinkan konektivitas masuk secara eksplisit, karena penyeimbang beban yang digunakan secara internal oleh API Management aman secara default dan menolak semua lalu lintas masuk. Untuk konfigurasi tertentu, lihat Mengonfigurasi aturan NSG, di bagian lain artikel ini.

  • Untuk skenario tertentu, aktifkan titik akhir layanan di subnet ke layanan dependen seperti Azure Storage atau Azure SQL. Untuk informasi selengkapnya, lihat Memaksa lalu lintas terowongan ke firewall lokal menggunakan ExpressRoute atau appliance virtual jaringan, nanti di artikel ini.

  • Alamat IPv4 publikSKU Standar. Sumber daya alamat IP publik diperlukan saat menyiapkan jaringan virtual untuk akses eksternal atau internal. Dengan jaringan virtual internal, alamat IP publik hanya digunakan untuk operasi manajemen. Mempelajari lebih lanjut tentang alamat IP API Management.

    • Alamat IP harus berada di wilayah dan langganan yang sama dengan instans API Management dan jaringan virtual.

    • Saat membuat sumber daya alamat IP publik, pastikan Anda menetapkan label nama DNS untuk sumber daya tersebut. Secara umum, Anda harus menggunakan nama DNS yang sama dengan instans API Management Anda. Jika Anda mengubahnya, sebarkan ulang instans Anda sehingga label DNS baru diterapkan.

    • Untuk performa jaringan terbaik, disarankan untuk menggunakan Preferensi perutean default: Jaringan Microsoft.

    • Saat membuat alamat IP publik di wilayah di mana Anda berencana mengaktifkan redundansi zona untuk instans API Management Anda, konfigurasikan pengaturan Redundan-zona.

    • Nilai alamat IP ditetapkan sebagai alamat IPv4 publik virtual dari instans API Management di wilayah tersebut.

    • Saat mengubah dari jaringan virtual eksternal ke internal (atau sebaliknya), mengubah subnet dalam jaringan, atau memperbarui zona ketersediaan untuk instans API Management, Anda harus mengonfigurasi alamat IP publik yang berbeda.

Mengaktifkan koneksi VNet

Mengaktifkan konektivitas VNet menggunakan portal Microsoft Azure (platform komputasi stv2)

  1. Buka portal Microsoft Azure untuk menemukan instans API Management Anda. Cari dan pilih layanan API Management.

  2. Pilih instans API Management Anda.

  3. Pilih Jaringan.

  4. Pilih tipe akses eksternal. Pilih VNET di portal Azure.

  5. Dalam daftar lokasi (wilayah) tempat layanan API Management Anda disediakan:

    1. Pilih Lokasi.
    2. Pilih Jaringan virtual, Subnet, dan Alamat IP.

    • Daftar VNet diisi dengan VNet Resource Manager yang tersedia di langganan Azure dan disiapkan di wilayah yang sedang Anda konfigurasi.

      Pengaturan VNet di portal.

  6. Pilih Terapkan. Halaman Jaringan instans API Management Anda diperbarui dengan pilihan VNet dan subnet baru Anda.

  7. Lanjutkan mengonfigurasi pengaturan VNet untuk lokasi yang tersisa dari instans API Management Anda.

  8. Di bilah navigasi atas, pilih Simpan, lalu pilih Terapkan konfigurasi jaringan.

Dibutuhkan waktu 15 hingga 45 menit untuk memperbarui instans API Management. Instans di tingkat Pengembang memiliki waktu henti selama proses. Instans di tingkat Premium tidak memiliki waktu henti selama proses.

Mengaktifkan konektivitas menggunakan templat Resource Manager (platform komputasi stv2)

  • Templat Azure Resource Manager (versi API 2021-08-01)

    Tombol untuk menyebarkan templat Resource Manager ke Azure.

Aktifkan konektivitas menggunakan cmdlet Azure PowerShell stv1 (platform)

Membuat atau memperbarui instans API Management di VNet.

Konfigurasikan aturan NSG

Konfigurasikan aturan jaringan kustom di subnet API Management untuk memfilter lalu lintas ke dan dari instans API Management Anda. Kami merekomendasikan aturan NSG minimum berikut untuk memastikan operasi dan akses yang tepat ke instans Anda. Tinjau lingkungan Anda dengan hati-hati untuk menentukan lebih banyak aturan yang mungkin diperlukan.

Penting

Bergantung pada penggunaan penembolokan dan fitur lainnya, Anda mungkin perlu mengonfigurasi aturan NSG tambahan di luar aturan minimum dalam tabel berikut. Untuk pengaturan terperinci, lihat Referensi konfigurasi jaringan virtual.

  • Untuk sebagian besar skenario, gunakan tag layanan yang ditunjukkan alih-alih alamat IP layanan untuk menentukan sumber dan tujuan jaringan.
  • Tetapkan prioritas aturan berikut lebih tinggi dari aturan default.
Port Sumber / Tujuan Petunjuk Protokol transportasi Tag layanan
Sumber / Tujuan		 Tujuan Jenis VNet
* / [80], 443 Masuk TCP Internet / VirtualNetwork Komunikasi klien ke API Management Hanya eksternal
* / 3443 Masuk TCP ApiManagement / VirtualNetwork Titik akhir manajemen untuk portal Microsoft Azure dan PowerShell Eksternal & Internal
* / 6390 Masuk TCP AzureLoadBalancer / VirtualNetwork Load Balancer Infrastruktur Azure Eksternal & Internal
* / 443 Masuk TCP AzureTrafficManager / VirtualNetwork Perutean Azure Traffic Manager untuk penyebaran multi-wilayah Hanya eksternal
* / 443 Keluar TCP VirtualNetwork / Storage Dependensi pada Azure Storage untuk fungsionalitas layanan inti Eksternal & Internal
* / 1433 Keluar TCP VirtualNetwork / SQL Akses ke titik akhir Azure SQL untuk fungsionalitas layanan inti Eksternal & Internal
* / 443 Keluar TCP VirtualNetwork / AzureKeyVault Akses ke Azure Key Vault untuk fungsionalitas layanan inti Eksternal & Internal
* / 1886, 443 Keluar TCP VirtualNetwork / AzureMonitor Memublikasikan Log dan Metrik Diagnostik, Kesehatan Sumber Daya, dan Application Insights Eksternal & Internal

Koneksi ke layanan web yang dihosting dalam jaringan virtual

Setelah menyambungkan layanan API Management ke VNet, Anda dapat mengakses layanan backend di dalamnya sama seperti Anda mengakses layanan publik. Saat membuat atau mengedit API, ketikkan alamat IP lokal atau nama host (jika server DNS dikonfigurasi untuk VNet) layanan web Anda di bidang URL layanan web.

Menambahkan API dari VNet

Penyiapan server DNS kustom

Dalam mode VNet eksternal, Azure mengelola DNS secara default. Anda dapat mengonfigurasi server DNS kustom secara opsional.

Layanan API Management bergantung pada beberapa layanan Azure. Ketika API Management dihost di VNet dengan server DNS kustom, manajemen ini perlu menyelesaikan nama host layanan Azure tersebut.

Penting

Jika Anda berencana menggunakan server DNS kustom untuk VNet, siapkan server DNS sebelum menyebarkan layanan API Management ke dalamnya. Jika tidak, Anda perlu memperbarui layanan API Management setiap kali Anda mengubah Server DNS dengan menjalankan Terapkan Operasi Konfigurasi Jaringan.

Perutean

  • Alamat IP publik (VIP) dengan beban seimbang dicadangkan untuk menyediakan akses ke semua titik akhir API Management dan sumber daya di luar VNET.
    • VIP publik dapat ditemukan pada bilah Gambaran Umum/Esensial di portal Microsoft Azure.

Untuk informasi dan pertimbangan selengkapnya, lihat Alamat IP Azure API Management.

Alamat VIP dan DIP

Alamat IP dinamis (DIP) akan ditetapkan ke setiap mesin virtual yang mendasarinya dalam layanan dan digunakan untuk mengakses titik akhir dan sumber daya di VNet dan di VNet yang di-peering. Alamat IP virtual publik (VIP) layanan API Management akan digunakan untuk mengakses sumber daya yang dapat diakses oleh publik.

Jika daftar pembatasan IP mengamankan sumber daya dalam VNet atau VNet yang di-peering, sebaiknya tentukan seluruh rentang subnet tempat layanan API Management disebarkan untuk memberikan atau membatasi akses dari layanan.

Pelajari selengkapnya tentang ukuran subnet yang disarankan.

Memaksa lalu lintas penerowongan ke firewall lokal Menggunakan ExpressRoute atau appliance virtual jaringan

Penerowongan paksa memungkinkan Anda mengalihkan atau "memaksa" semua lalu lintas yang terikat dengan internet dari subnet Anda untuk kembali ke lokal guna diperiksa dan diaudit. Biasanya, Anda dapat mengonfigurasi dan menentukan rute default Anda sendiri (0.0.0.0/0), memaksa semua lalu lintas dari subnet API Management mengalir melalui firewall lokal atau ke appliance virtual jaringan. Arus lalu lintas ini memutus konektivitas dengan API Management karena lalu lintas keluar diblokir secara lokal, atau diblokir melalui proses NAT sehingga menjadi serangkaian alamat yang tidak dapat dikenali dan tidak lagi berfungsi dengan berbagai titik akhir Azure. Anda dapat menyelesaikan masalah ini melalui salah satu metode berikut:

  • Mengaktifkan titik akhir layanan pada subnet tempat layanan API Management disebarkan:

    • Azure SQL (hanya diperlukan di wilayah utama jika layanan API Management disebarkan ke beberapa wilayah)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (diperlukan saat API Management disebarkan pada platform stv2)

    Dengan mengaktifkan titik akhir langsung dari subnet API Management ke layanan ini, Anda dapat menggunakan jaringan backbone Microsoft Azure, menyediakan perutean yang optimal untuk lalu lintas layanan. Jika Anda menggunakan titik akhir layanan dengan API Management yang disalurkan secara paksa, lalu lintas untuk layanan Azure sebelumnya tidak dialihkan secara paksa. Namun, lalu lintas dependensi layanan API Management lainnya tetap disalurkan secara paksa. Pastikan firewall atau appliance virtual Anda tidak memblokir lalu lintas ini, atau layanan API Management mungkin tidak berfungsi dengan baik.

    Catatan

    Kami sangat menyarankan untuk mengaktifkan titik akhir layanan langsung dari subnet API Management ke layanan dependen seperti Azure SQL dan Azure Storage yang mendukungnya. Namun, beberapa organisasi mungkin memiliki persyaratan untuk memaksa terowongan semua lalu lintas dari subnet API Management. Dalam hal ini, pastikan Anda mengonfigurasi firewall atau appliance virtual untuk memungkinkan lalu lintas ini. Anda harus mengizinkan rentang alamat IP lengkap dari setiap layanan dependen, dan menjaga konfigurasi ini tetap terbarui saat infrastruktur Azure berubah. Layanan API Management Anda mungkin juga mengalami latensi atau batas waktu yang tidak terduga karena penerowongan paksa lalu lintas jaringan ini.

  • Semua lalu lintas sarana kontrol dari internet ke titik akhir manajemen layanan API Management Anda dirutekan melalui serangkaian IP masuk tertentu, yang dihosting oleh API Management, yang disertai oleh tag layanan ApiManagement. Ketika lalu lintas disalurkan secara paksa, respons tidak akan secara simetris memetakan kembali ke IP sumber masuk ini dan konektivitas ke titik akhir manajemen hilang. Untuk mengatasi batasan ini, konfigurasikan rute yang ditentukan pengguna (UDR) untuk tag layanan ApiManagement dengan jenis hop berikutnya diatur ke "Internet", untuk mengarahkan lalu lintas kembali ke Azure.

    Catatan

    Mengizinkan lalu lintas pengelola API Management melewati firewall lokal atau appliance virtual jaringan tidak dianggap sebagai risiko keamanan yang signifikan. Konfigurasi yang disarankan untuk subnet API Management Anda memungkinkan lalu lintas manajemen masuk pada port 3443 hanya dari kumpulan alamat IP Azure yang mencakup tag layanan ApiManagement. Konfigurasi UDR yang disarankan hanya untuk jalur pengembalian lalu lintas Azure ini.

  • (Mode VNet Eksternal) Lalu lintas sarana data untuk klien yang mencoba mencapai gateway API Management dan portal pengembang dari internet juga akan dihilangkan secara default karena perutean asimetris yang diperkenalkan oleh penerowongan paksa. Untuk setiap klien yang memerlukan akses, konfigurasikan UDR eksplisit dengan jenis hop berikutnya "Internet" untuk melewati firewall atau appliance jaringan virtual.

  • Untuk dependensi layanan API Management lainnya yang berupa terowongan paksa, harus ada cara untuk menyelesaikan nama host dan menjangkau titik akhir. Ini termasuk:

    • Pemantuan Metrik dan Kesehatan
    • Diagnostik portal Microsoft Azure
    • Relai SMTP
    • CAPTCHA Portal pengembang
    • Server Azure KMS

Untuk informasi selengkapnya, lihat Referensi konfigurasi jaringan virtual.

Masalah konfigurasi jaringan umum

Bagian ini telah dipindahkan. Lihat Referensi konfigurasi jaringan virtual.

Pemecahan Masalah

Penyebaran awal layanan API Management tidak berhasil ke dalam subnet

  • Sebarkan komputer virtual ke subnet yang sama.
  • Koneksi ke komputer virtual dan validasi konektivitas ke salah satu dari masing-masing sumber daya berikut dalam langganan Azure Anda:
    • Blob Azure Storage
    • Database Azure SQL
    • Tabel Azure Storage
    • Azure Key Vault (untuk instans API Management yang dihosting di platform stv2)

Penting

Setelah memvalidasi konektivitas, hapus semua sumber daya di subnet sebelum menerapkan API Management ke subnet (diperlukan saat API Management dihosting di platform stv1).

Memverifikasi Status Jaringan

  • Setelah menyebarkan API Management ke subnet, gunakan portal untuk memeriksa konektivitas instans Anda ke dependensi seperti Azure Storage.

  • Di portal, di menu sebelah kiri, pada Penyebaran dan infrastruktur, pilih Jaringan>Status jaringan.

    Cuplikan layar verifikasi status konektivitas jaringan di portal.

Filter Deskripsi
Diperlukan Pilih untuk meninjau konektivitas layanan Azure yang diperlukan untuk API Management. Kegagalan menunjukkan bahwa instans tidak dapat melakukan operasi inti untuk mengelola API.
Opsional Pilih untuk meninjau konektivitas layanan opsional. Kegagalan hanya menunjukkan bahwa fungsionalitas tertentu tidak akan berfungsi (misalnya, SMTP). Kegagalan dapat menyebabkan degradasi dalam hal penggunaan dan pemantauan instans API Management serta penyediaan SLA dengan komitmen tinggi.

Untuk membantu memecahkan masalah konektivitas, pilih:

  • Metrik - untuk meninjau metrik status konektivitas jaringan

  • Diagnosis - untuk menjalankan pemverifikasi jaringan virtual selama periode waktu tertentu

Untuk mengatasi masalah konektivitas, tinjau Masalah konfigurasi jaringan dan perbaiki pengaturan jaringan yang diperlukan.

Pembaruan bertahap

Saat membuat perubahan pada jaringan Anda, lihat NETWORKStatus API untuk memverifikasi bahwa layanan API Management belum kehilangan akses ke sumber daya penting. Status konektivitas harus diperbarui setiap 15 menit.

Untuk menerapkan perubahan konfigurasi jaringan ke instans API Management menggunakan portal:

  1. Di menu sebelah kiri untuk instans Anda, di bawah Penyebaran dan infrastruktur, pilih Jaringan>Virtual.
  2. Pilih Terapkan konfigurasi jaringan.

Instans API Management yang dihosting di stv1 platform komputasi, saat disebarkan ke subnet VNet Resource Manager, mencadangkan subnet dengan membuat tautan navigasi sumber daya. Jika subnet sudah berisi sumber daya dari penyedia lain, penyebaran akan gagal. Demikian pula, ketika Anda menghapus layanan API Management atau memindahkannya ke subnet yang berbeda, tautan navigasi sumber daya akan dihapus.

Tantangan yang dihadapi dalam menetapkan ulang instans API Management ke subnet sebelumnya

  • Kunci VNet - Saat memindahkan instans API Management kembali ke subnet aslinya, penugasan ulang segera mungkin tidak dimungkinkan karena kunci VNet, yang membutuhkan waktu hingga enam jam untuk dihapus. Jika subnet asli memiliki layanan API Management berbasis platform lainnya stv1 (berbasis layanan cloud), menghapusnya dan menunggu selama 6 jam diperlukan untuk menyebarkan stv2 layanan berbasis platform di subnet yang sama.
  • Kunci grup sumber daya - Skenario lain yang perlu dipertimbangkan adalah adanya kunci cakupan di tingkat grup sumber daya atau yang lebih tinggi, menghambat proses Penghapusan Tautan Navigasi Sumber Daya. Untuk mengatasinya, hapus kunci cakupan dan izinkan penundaan sekitar 4-6 jam agar layanan API Management membatalkan tautan dari subnet asli sebelum penghapusan kunci, memungkinkan penyebaran ke subnet yang diinginkan.

Memecahkan masalah koneksi ke Microsoft Graph dari dalam VNet

Konektivitas jaringan ke Microsoft Graph diperlukan untuk fitur termasuk masuk pengguna ke portal pengembang menggunakan penyedia identitas Microsoft Entra.

Untuk memecahkan masalah konektivitas ke Microsoft Graph dari dalam VNet:

  • Pastikan bahwa NSG dan aturan jaringan lainnya dikonfigurasi untuk konektivitas keluar dari instans API Management Anda ke Microsoft Graph (menggunakan tag layanan AzureActiveDirectory ).

  • Pastikan resolusi DNS dan akses jaringan ke graph.microsoft.com dari dalam VNet. Misalnya, provisikan VM baru di dalam VNet, sambungkan, dan coba GET https://graph.microsoft.com/v1.0/$metadata dari browser atau menggunakan cURL, PowerShell, atau alat lainnya.

Langkah berikutnya

Pelajari lebih lanjut tentang: