FAQ Provisioning - Web Application Firewall

Topik ini mencantumkan masalah umum Web Application Firewall (WAF) 3.0 yang mungkin Anda temui selama proses provisioning.

Ikhtisar

Kemampuan dan konfigurasi pra-provisioning
Masalah selama provisioning
Masalah pasca-provisioning

Apa perbedaan antara alamat IP asal dan alamat IP kembali-ke-asal di WAF?

Alamat IP Kembali-ke-Asal WAF Alamat IP Kembali-ke-Asal WAF adalah rentang alamat IP yang digunakan WAF untuk meneruskan lalu lintas normal ke server asal Anda setelah lalu lintas diproses. Alamat IP ini ditetapkan oleh Alibaba Cloud dan mengidentifikasi WAF sebagai sumber permintaan yang dikirim ke server asal.
- Alamat IP Kembali-ke-Asal biasanya merupakan rentang alamat IP tetap.
- Dari sudut pandang server asal, semua permintaan dari klien diintercept dan diteruskan oleh WAF. Alamat IP klien nyata dicatat dalam bidang header HTTP, seperti X-Forwarded-For atau header kustom.
Alamat IP Asal Alamat IP Asal adalah alamat IP publik server backend yang menyelenggarakan layanan Anda, atau alamat IP tempat nama domainnya diselesaikan. Ini adalah alamat tujuan yang menerima permintaan dan mengembalikan tanggapan ketika pengguna mengakses situs web Anda.
- Alamat IP Asal bisa berupa satu alamat IP atau beberapa alamat IP untuk penyeimbangan beban.
- Alamat IP Asal adalah titik akhir aktual situs web Anda. Itu dapat diterapkan pada layanan Alibaba Cloud seperti ECS, SLB, dan OSS, atau pada layanan dari penyedia cloud lainnya.

Bisakah nama domain yang sama menggunakan mode cloud native dan jenis koneksi CNAME pada saat yang bersamaan?

Tidak. Setiap nama domain hanya dapat menggunakan satu mode provisioning, baik cloud native maupun CNAME. Menggunakan kedua mode untuk nama domain yang sama menyebabkan konflik forwarding dan menonaktifkan perlindungan. Jika Anda memiliki nama domain yang dilindungi oleh WAF dalam mode CNAME dan ingin beralih ke mode cloud native, Anda harus terlebih dahulu menghapus konfigurasi provisioning CNAME untuk nama domain tersebut. Kemudian, Anda dapat memprovisioning nama domain dalam mode cloud native.

Bisakah WAF melindungi beberapa alamat IP asal di bawah satu nama domain?

Ya. Anda dapat mengonfigurasi hingga 20 Alamat IP Asal untuk satu nama domain di WAF.

Apakah WAF mendukung pemeriksaan kesehatan?

Ya, WAF mengaktifkan pemeriksaan kesehatan secara default. WAF memeriksa status kesehatan semua Alamat IP Asal. Jika Alamat IP Asal tidak merespons, WAF meneruskan permintaan akses ke Alamat IP Asal lain yang sehat.

Jika Alamat IP Asal tidak merespons, WAF secara otomatis menetapkan periode diam untuknya. Setelah periode diam berakhir, WAF mungkin mencoba meneruskan permintaan akses baru ke Alamat IP Asal tersebut.

Bisakah alamat IP eksklusif WAF mempertahankan diri dari serangan DDoS?

Alamat IP Eksklusif mencegah serangan DDoS skala besar pada satu nama domain membuat nama domain lain yang diprovisioning tidak dapat diakses. Untuk informasi lebih lanjut, lihat Nilai Alamat IP Eksklusif.

Bisakah WAF diprovisioning dengan CDN atau Anti-DDoS Pro dan Anti-DDoS Premium?

Ya, WAF sepenuhnya kompatibel dengan CDN dan Anti-DDoS Pro dan Anti-DDoS Premium. Ketika Anda menggunakan WAF dengan Anti-DDoS atau CDN, Anda harus menetapkan alamat CNAME yang disediakan oleh WAF sebagai alamat asal untuk Anti-DDoS atau CDN. Arsitektur ini memastikan bahwa lalu lintas melewati Anti-DDoS atau CDN, diteruskan ke WAF, dan kemudian mencapai server asal. Penyebaran ini memberikan perlindungan keamanan komprehensif untuk server asal Anda. Untuk informasi lebih lanjut, lihat Tingkatkan keamanan situs web dengan menerapkan Anti-DDoS Pro atau Anti-DDoS Premium dan WAF dan Terapkan WAF dan CDN untuk melindungi nama domain yang telah diaktifkan CDN.

Apakah WAF mendukung arsitektur lintas akun yang menggunakan CDN, Anti-DDoS, dan WAF?

Ya. Anda dapat menggunakan portofolio produk lintas akun dari CDN, Anti-DDoS, dan WAF untuk membangun arsitektur keamanan yang mempertahankan diri dari serangan DDoS dan serangan aplikasi web.

Bagaimana cara WAF memastikan keamanan sertifikat dan kunci yang diunggah? Apakah WAF mendekripsi lalu lintas HTTPS dan mencatat isi permintaan akses?

Ketika melindungi layanan HTTPS, Alibaba Cloud WAF memerlukan Anda untuk mengunggah Sertifikat SSL dan kunci yang sesuai untuk mendekripsi lalu lintas HTTPS dan memeriksanya untuk tanda-tanda serangan. Kami menggunakan Key Server khusus untuk menyimpan dan mengelola kunci. Key Server bergantung pada Alibaba Cloud Key Management Service (KMS) untuk melindungi keamanan data, integritas, dan ketersediaan sertifikat dan kunci, memenuhi persyaratan regulasi dan kepatuhan perlindungan terklasifikasi. Untuk informasi lebih lanjut tentang KMS, lihat Apa itu KMS?.

WAF menggunakan Sertifikat SSL dan kunci yang Anda unggah untuk mendekripsi lalu lintas HTTPS hanya untuk inspeksi real-time. Kami hanya mencatat bagian dari isi permintaan yang berisi tanda-tanda serangan (payload) untuk tujuan seperti menampilkan laporan serangan dan statistik data. Kami tidak mencatat konten penuh dari permintaan atau tanggapan tanpa otorisasi Anda.

Alibaba Cloud WAF telah memperoleh beberapa sertifikasi otoritatif internasional, seperti ISO 9001, ISO 20000, ISO 22301, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 29151, BS 10012, CSA STAR, Tingkat Kepatuhan Perlindungan Terklasifikasi Level 3, SOC 1/2/3, C5, HK Finance, OSPAR, dan PCI DSS. Sebagai produk standar Alibaba Cloud, ia memiliki tingkat keamanan dan kualifikasi kepatuhan yang sama dengan platform Alibaba Cloud. Untuk informasi lebih lanjut, lihat Pusat Kepercayaan Alibaba Cloud.

Situs web saya dilindungi oleh WAF, tetapi mengapa saya tidak dapat menemukannya dalam daftar nama domain?

Pendaftaran ICP situs web Anda mungkin telah kedaluwarsa, yang menyebabkan nama domain tidak lagi memenuhi persyaratan provisioning. WAF secara otomatis membersihkan nama domain tersebut dari daftar yang dilindungi. Anda harus menyelesaikan pendaftaran ICP untuk nama domain tersebut dan kemudian menambahkan situs web ke WAF lagi. Untuk informasi lebih lanjut tentang pendaftaran ICP Alibaba Cloud, lihat Proses Pendaftaran ICP.

Penting

Sebelum Anda melindungi situs web Anda dengan instans WAF di Daratan Tiongkok, Anda harus memastikan bahwa nama domain memiliki pendaftaran ICP yang valid. Untuk mematuhi undang-undang dan peraturan terkait, instans WAF di Daratan Tiongkok secara berkala membersihkan nama domain dengan pendaftaran ICP yang kedaluwarsa.

Bagaimana cara WAF menggunakan header kustom untuk mendapatkan dan mencatat alamat IP sumber klien?

Mendapatkan alamat IP sumber klien dari header kustom: Jika layanan proxy Lapisan 7 lainnya, seperti Anti-DDoS Pro dan Anti-DDoS Premium atau CDN, diterapkan di depan WAF, Anda dapat menggunakan header kustom untuk menyimpan alamat IP klien. Metode ini meningkatkan keamanan dengan mencegah penyerang memalsukan header X-Forwarded-For (XFF) untuk melewati aturan deteksi WAF. Untuk melakukannya, letakkan alamat IP sumber klien di bidang header kustom, seperti X-Client-IP atau X-Real-IP, dan konfigurasikan WAF untuk membaca dari bidang header tersebut. WAF kemudian mengambil nilai bidang header yang ditentukan sebagai alamat IP sumber klien. Jika Anda menentukan beberapa bidang header, WAF mencoba membaca alamat IP klien dari header dalam urutan yang ditentukan.

Mencatat alamat IP klien dalam header kustom: Ketika Anda menambahkan situs web untuk perlindungan WAF, Anda dapat mengaktifkan penandaan lalu lintas. Fitur ini menyebabkan WAF menulis alamat IP klien ke bidang header kustom dari permintaan klien. Server backend kemudian dapat memperoleh alamat IP klien dari bidang header yang ditentukan dalam permintaan kembali-ke-asal yang diteruskan oleh WAF. Ini berguna untuk skenario di mana server backend perlu memperoleh alamat IP klien dari header kustom tertentu untuk analisis bisnis.

Nama domain yang sama diarahkan ke beberapa instans produk cloud. Bagaimana saya harus memprovisioning mereka?

Jika Anda menggunakan mode cloud native, Anda harus memprovisioning semua instans produk cloud ini, misalnya, port layanan instans SLB, pada saat yang bersamaan. Ini memungkinkan WAF untuk mengalihkan lalu lintas untuk semuanya.

Jika Anda menggunakan mode CNAME, setelah Anda menambahkan nama domain, semua instans produk cloud dilindungi oleh kebijakan mitigasi default WAF.

Beberapa resolusi nama domain mengarah ke instans produk cloud yang sama. Bagaimana saya harus memprovisioning mereka?

Ketika Anda menggunakan mode cloud native, semua nama domain pada instans produk cloud yang diprovisioning dilindungi oleh kebijakan mitigasi default WAF. Namun, jika Anda ingin mengonfigurasi aturan perlindungan yang berbeda untuk nama domain individu, Anda harus menambahkannya sebagai objek yang dilindungi. Untuk informasi lebih lanjut, lihat Tambahkan Objek yang Dilindungi secara Manual.

Jika Anda menggunakan mode CNAME, Anda harus menambahkan nama domain satu per satu.

Apa saja akhiran nama domain yang didukung untuk provisioning CNAME?

WAF 3.0 mendukung sebagian besar akhiran nama domain, termasuk akhiran nama domain dalam bahasa Mandarin. Untuk daftar akhiran bahasa Mandarin yang didukung, lihat iana.org.

WAF 3.0 mendukung lebih banyak akhiran nama domain daripada WAF 2.0. Jika Anda menemukan bahwa nama domain tidak didukung untuk provisioning di WAF 2.0, kami sarankan Anda meningkatkan ke WAF 3.0.

Apakah WAF mendukung otentikasi timbal balik HTTPS?

Tidak, mode CNAME dan mode proxy transparan tidak mendukung otentikasi timbal balik HTTPS. Namun, solusi provisioning berbasis layanan untuk WAF 3.0 mendukungnya. Saat ini, produk cloud yang mendukung provisioning berbasis layanan termasuk ALB, MSE, FC, dan SAE. Anda dapat mengonfigurasi jenis provisioning ini di bagian Mode Cloud Native pada konsol WAF.

Apakah WAF mendukung protokol WebSocket, HTTP 2.0, atau SPDY?

WAF mendukung protokol WebSocket. Edisi Perusahaan dan rencana langganan yang lebih tinggi, bersama dengan rencana bayar sesuai penggunaan, mendukung pendengaran untuk protokol HTTP 2.0. Protokol SPDY tidak didukung.

Untuk mencegah penyerang menggunakan cleartext smuggling HTTP 2.0 untuk melewati WAF, Anda dapat membuat aturan kustom untuk memblokir permintaan di mana nama Header adalah Upgrade dan nilainya adalah h2c. Untuk informasi lebih lanjut, lihat Buat Aturan Kustom untuk Mempertahankan Diri dari Permintaan Tertentu.

Apakah melindungi layanan HTTP 2.0 dengan WAF mempengaruhi server asal?

Ya. Melindungi layanan HTTP 2.0 dengan WAF berarti bahwa WAF dapat memproses permintaan HTTP 2.0 dari klien. Namun, WAF saat ini hanya mendukung penerusan permintaan kembali-ke-asal melalui HTTP 1.0/1.1. HTTP 2.0 belum didukung antara WAF dan server asal. Oleh karena itu, jika Anda melindungi layanan HTTP 2.0 dengan WAF, fitur HTTP 2.0 dari server asal akan terpengaruhi. Misalnya, fitur multiplexing HTTP 2.0 dari server asal mungkin menjadi tidak efektif, yang menyebabkan peningkatan bandwidth layanan server asal.

Apakah WAF mendukung provisioning untuk situs web yang menggunakan otentikasi protokol NTLM?

Tidak. Jika situs web menggunakan otentikasi protokol NTLM, permintaan akses yang diteruskan oleh WAF mungkin gagal dalam otentikasi NTLM server asal. Klien terus melihat prompt otentikasi. Kami menyarankan Anda menggunakan metode lain untuk otentikasi situs web.

Apakah batas QPS WAF berlaku untuk seluruh instans WAF atau batas atas untuk nama domain tunggal yang dikonfigurasi?

Batas queries per detik (QPS) WAF berlaku untuk seluruh instans WAF.

Sebagai contoh, jika Anda telah mengonfigurasi tiga nama domain untuk perlindungan pada instans WAF, total QPS untuk ketiga nama domain tersebut tidak boleh melebihi batas yang ditentukan. Jika QPS melebihi batas instans WAF yang Anda beli, instans tersebut mungkin masuk ke sandbox. Jika QPS aktual melebihi spesifikasi atau instans masuk ke sandbox, produk tersebut tidak lagi dijamin mengikuti Service-Level Agreement (SLA).

Bagaimana cara melihat rentang IP kembali-ke-asal WAF dan CNAME yang disediakan oleh WAF?

Anda dapat menemukan rentang IP Kembali-ke-Asal WAF dan alamat CNAME yang disediakan oleh WAF untuk setiap nama domain yang diprovisioning di lokasi yang ditunjukkan pada gambar berikut di halaman Daftar Provisioning.

Pemecahan masalah ketika instans SLB, NLB, atau ECS yang akan diprovisioning tidak dapat ditemukan di halaman konfigurasi

Penyebab yang mungkin	Operasi terkait
Instans SLB, NLB, atau ECS yang akan diprovisioning tidak memenuhi persyaratan.	Periksa instans terhadap persyaratan provisioning. Untuk informasi lebih lanjut tentang persyaratan, lihat Persyaratan Provisioning Instans SLB, Persyaratan Provisioning Instans NLB, dan Persyaratan Provisioning Instans ECS.
Tidak ada pendengar yang sesuai yang ditambahkan ke instans SLB yang akan diprovisioning.	Untuk informasi lebih lanjut tentang cara menambahkan pendengar ke instans SLB Lapisan 7, lihat Tambahkan Pendengar HTTP dan Tambahkan Pendengar HTTPS. Untuk informasi lebih lanjut tentang cara menambahkan pendengar ke instans SLB Lapisan 4, lihat Tambahkan Pendengar TCP.
WAF gagal menyinkronkan dengan instans SLB, NLB, atau ECS	Untuk langkah-langkah spesifik untuk menyinkronkan aset, lihat Sinkronkan Aset secara Manual.

Ketika menambahkan port pengalihan lalu lintas HTTPS, sebuah pesan menunjukkan bahwa Sertifikat SLB tidak lengkap. Apa yang harus saya lakukan?

Deskripsi masalah

Ketika Anda menambahkan port pengalihan lalu lintas HTTPS, WAF memvalidasi sumber sertifikat yang dikonfigurasikan untuk port tersebut. Setelah Anda menambahkan port, pesan berikut muncul: Sertifikat SLB untuk port XXX tidak lengkap. Buka konsol SLB dan pilih ulang sertifikat dari Layanan Sertifikat.

Penyebab yang mungkin

Sertifikat yang dikonfigurasikan tidak dibeli dari Alibaba Cloud Certificate Management Service (Original SSL Certificate) dan belum diunggah ke Alibaba Cloud Certificate Management Service (Original SSL Certificate).
Sertifikat untuk pendengar port HTTPS instans SLB diunggah melalui konsol SLB. Namun, metode unggah ini tidak secara otomatis menyinkronkan informasi sertifikat ke Layanan Manajemen Sertifikat (Sertifikat SSL Asli). Karena WAF hanya mengambil informasi sertifikat dari Layanan Manajemen Sertifikat, WAF tidak dapat memperoleh konten sertifikat lengkap, yang menyebabkan munculnya pesan 'sertifikat tidak lengkap'.
Sertifikat yang sebelumnya Anda unggah telah dihapus secara manual, dan sertifikat Anda tidak lagi ada di Certificate Management Service (Original SSL Certificate).

Solusi

Unggah sertifikat Anda ke Certificate Management Service (Original SSL Certificate). Untuk informasi lebih lanjut, lihat Unggah Sertifikat SSL.
Buat sertifikat di konsol SLB dan pilih Sertifikat yang Dikeluarkan Alibaba Cloud sebagai sumber sertifikat. Untuk informasi lebih lanjut, lihat Pilih Sertifikat yang Dikeluarkan Alibaba Cloud.
Di konsol SLB, pilih sertifikat server yang diunggah. Untuk informasi lebih lanjut, lihat Langkah 2: Konfigurasikan Sertifikat SSL.

Untuk alamat IP asal di WAF, apakah saya harus memasukkan alamat IP publik atau alamat IP pribadi dari instans ECS?

Anda harus memasukkan Alamat IP Publik. WAF menggunakan Internet untuk pengambilan asal dan tidak mendukung Alamat IP Pribadi.

Alamat IP publik server asal terpapar. Bagaimana jika seorang penyerang melewati WAF dengan langsung menyerang alamat IP publik asal?

Anda dapat menggunakan salah satu dari metode berikut: Metode 1: Dalam mode CNAME, konfigurasikan server asal untuk mengizinkan lalu lintas hanya dari rentang IP Kembali-ke-Asal WAF. Ini memastikan bahwa hanya WAF yang dapat berkomunikasi dengan server asal. Untuk informasi lebih lanjut, lihat Izinkan Alamat IP Kembali-ke-Asal WAF.

Metode 2: Gunakan mode cloud native.

Beberapa skenario menerima kode status 502 setelah memprovisioning WAF

Deskripsi masalah

Setelah Anda memprovisioning WAF, mengakses layanan backend mengembalikan kode status 502. Log menunjukkan permintaan dengan kode status 502.

Penyebab dan solusi

Skenario 1: Kesalahan 502 dalam mode CNAME

Dalam mode CNAME, kesalahan 502 mungkin terjadi jika server asal, seperti instans ECS atau SLB, tidak dapat diakses oleh WAF. Kami menyarankan Anda pertama-tama memeriksa aturan atau perangkat lunak apa pun yang mungkin membatasi akses WAF, seperti grup keamanan, iptables, firewall, Safedog, atau Yunsuo. Sebagai contoh, Anda perlu mengizinkan rentang IP Kembali-ke-Asal WAF dalam grup keamanan instans ECS Anda.

Anda juga perlu memastikan bahwa informasi nama domain dan server asal yang digunakan oleh layanan Anda dikonfigurasikan di konsol WAF. Ketidakcocokan antara informasi nama domain dan server asal juga dapat menyebabkan kesalahan ini.

Skenario 2: Kesalahan 5xx intermiten dengan SLB Lapisan 7 dalam mode cloud native

Analisis penyebab detail

Timeout idle koneksi kembali-ke-asal WAF: 3.600 detik (1 jam)

Deskripsi: Ketika tidak ada transmisi data antara SLB dan WAF selama 1 jam, WAF secara otomatis menutup koneksi.

Timeout idle koneksi client-facing SLB: 15 detik

Deskripsi: Ketika tidak ada transmisi data antara klien (dalam hal ini, instans WAF) dan SLB selama 15 detik, SLB secara otomatis menutup koneksi.

Dalam kasus ekstrem, koneksi persisten kedaluwarsa di sisi SLB (tidak ada transfer data selama lebih dari 15 detik). Pada saat itu, permintaan kembali-ke-asal WAF menggunakan kembali koneksi persisten tersebut untuk mengirim data ke SLB. Karena SLB tidak lagi memiliki informasi tentang koneksi persisten, ia mengirimkan pesan RST untuk mengakhiri permintaan. Ini menghasilkan entri log dengan kode status 502 di sisi WAF.

Solusi

Atur ulang Idle Timeout untuk SLB Lapisan 7 dalam mode cloud native. Tetapkan nilainya kurang dari timeout idle koneksi client-facing SLB, misalnya, 14 detik.

Skenario 3: Kesalahan 502 intermiten karena URI panjang

Analisis penyebab detail

SLB Lapisan 7 adalah hop berikutnya setelah WAF meneruskan lalu lintas. Namun, SLB memiliki batas panjang URI sebesar 32 KB. Jika panjang URI permintaan melebihi panjang yang dapat diurai oleh server SLB, SLB menolak permintaan. SLB mencatat kode status 414, dan WAF mengembalikan kode status 502.

Solusi

Persingkat panjang URI. Jika volume data besar, kami menyarankan Anda menggunakan POST untuk mentransmisikan data.

Skenario 4: Kesalahan 502 intermiten ketika WAF mengirim permintaan kembali-ke-asal ke beberapa SLB Lapisan 4

Arsitektur jaringan saat ini

Dalam arsitektur saat ini, WAF diprovisioning dalam mode reverse proxy dan mengirim permintaan kembali-ke-asal ke beberapa SLB Lapisan 4. Backend RealServers (RSs) mendengarkan pada port yang sama dan dilampirkan ke beberapa SLB Lapisan 4.

Analisis penyebab detail

Ketika instans ECS berfungsi sebagai server backend untuk beberapa instans SLB Lapisan 4 (TCP), dan instans SLB ini dikonfigurasikan dengan port layanan backend yang sama, berikut ini mungkin terjadi: Jika permintaan klien dikirim dari node instans WAF yang sama dalam kluster WAF ke SLB, dan alamat IP node WAF yang sama digunakan untuk mengakses layanan frontend instans SLB ini secara bersamaan, beberapa koneksi mungkin gagal atau timeout.

Kasus 1: Konflik 5-tuple, tabrakan aliran TCP

Ketika kluster WAF memberikan perlindungan keamanan untuk beberapa node SLB, permintaan ke node SLB ini mungkin berasal dari alamat IP Kembali-ke-Asal WAF yang sama.

Ketika node instans WAF mengirim permintaan kembali-ke-asal untuk mengakses CLB1, koneksi (WIP:CPORT->VIP1:VPORT1) diubah menjadi (WIP:CPORT->DIP:DPORT) ketika mencapai backend ECS.
Ketika node instans WAF yang sama mengirim permintaan kembali-ke-asal untuk mengakses CLB2, koneksi (WIP:CPORT->VIP2:VPORT2) juga diubah menjadi (WIP:CPORT->DIP:DPORT) ketika mencapai backend ECS.
Karena nomor urutan dan status dari dua koneksi TCP bertentangan di server backend, koneksi gagal dibuat. Secara khusus, dua koneksi TCP yang diinisiasi dilihat oleh server backend sebagai memiliki 5-tuple yang sama (TCP:WIP:CPORT:DIP:DPORT). Konflik 5-tuple ini dapat menyebabkan pesan SYN dijatuhkan.

Kasus 2: Jalur pengembalian pesan yang salah

Dalam jalur permintaan lengkap, node SLB yang memulai permintaan berbeda dari node SLB yang menerima pesan tanggapan.

WAF mengirim pesan SYN kembali-ke-asal melalui CLB2. 5-tuple adalah WIP:CPORT->VIP1:VPORT1. Ketika mencapai backend ECS2, diubah menjadi WIP:CPORT->DIP:DPORT.
Jika ECS2 memiliki koneksi TIME-WAIT dengan 5-tuple TCP:WIP:CPORT:DIP:DPORT pada saat itu, ia menerima pesan SYN dari langkah pertama, menentukan bahwa itu sah, dan merespons dengan pesan SYN-ACK.
Karena ECS2 dilampirkan ke beberapa SLB, ia mungkin mengirim pesan SYN-ACK kembali ke CLB1. Jika CLB1 tidak memiliki sesi untuk 5-tuple ini, CLB1 mengirim reset dua arah untuk paket tersebut. Ini menyebabkan WAF mengembalikan kesalahan 502.

Solusi

Solusi 1 (Direkomendasikan)

Ubah arsitektur jaringan. Sebagai contoh, gunakan beberapa SLB Lapisan 7 sebagai server asal untuk menghindari beberapa node SLB Lapisan 4 yang berbeda meneruskan permintaan ke port yang sama dari layanan backend yang sama.

Solusi 2

Migrasikan dari SLB ke NLB. Dalam konfigurasi, nonaktifkan afinitas alamat IP klien untuk menyelesaikan masalah konflik 5-tuple. Terapkan Fitur Proxy Protocol pada layanan backend untuk mendapatkan alamat IP klien nyata. Untuk informasi lebih lanjut, lihat Dapatkan Alamat IP Klien Menggunakan Fitur Proxy Protocol.

Prosedur

Masuk ke Konsol NLB.Di bilah menu atas, pilih wilayah tempat instans NLB diterapkan.
Di panel navigasi di sebelah kiri, pilih Network Load Balancer (NLB) > Server Groups.
Pilih grup server Anda dan klik Edit Informasi Dasar di kolom Tindakan. Di kotak dialog Edit Informasi Dasar, nonaktifkan Afinitas Alamat IP Klien dan simpan perubahan.

Solusi 3 (Tidak direkomendasikan)

Anda dapat mengirimkan tiket untuk mengaktifkan mode FULLNAT. Ketika beberapa instans SLB meneruskan permintaan ke port yang sama dari server backend yang sama, FullNAT menghindari konflik dengan memodifikasi alamat sumber, sehingga membuat 5-tuple setiap koneksi unik. Aktifkan mode FULLNAT untuk pendengar SLB untuk menghindari konflik 5-tuple.

Pengunggahan file gagal setelah memprovisioning WAF

Masalah ini mungkin terjadi karena pengunggahan file melebihi batas ukuran. WAF mendukung ukuran unggah file maksimum sebesar 2 GB. Jika badan permintaan melebihi 2 GB, WAF mengembalikan kode status 413. Anda dapat memeriksa kode status yang dikembalikan untuk menentukan apakah batas ukuran transfer file telah tercapai.

Bagaimana cara memperbarui sertifikat yang akan segera kedaluwarsa?

Metode pembaruan bervariasi tergantung pada mode provisioning:

Untuk mode CNAME, lihat Perbarui Sertifikat yang Terikat ke Nama Domain.
Untuk mode cloud native dengan instans ECS, lihat Perbarui Sertifikat yang Terikat ke Port Pengalihan Lalu Lintas ECS.
Untuk mode cloud native dengan instans SLB, lihat Perbarui Sertifikat yang Terikat ke Port Pengalihan Lalu Lintas SLB.
Untuk mode cloud native dengan instans NLB, lihat Perbarui Sertifikat yang Terikat ke Port Pengalihan Lalu Lintas NLB.
Jika menggunakan mode cloud native untuk Instans ALB, Anda tidak perlu memperbaruinya di konsol WAF. Cukup terapkan sertifikat ke Instans ALB di konsol Certificate Management Service (Original SSL Certificate). Untuk informasi lebih lanjut, lihat Terapkan Sertifikat SSL ke Layanan Alibaba Cloud.

Setelah provisioning cloud native, apakah server asal dapat memperoleh alamat IP klien sebenarnya?

Ya, bisa. WAF secara langsung menyediakan alamat IP klien sebenarnya ke instans produk cloud.