Jika konversi dari lalu lintas seluler tiba-tiba menurun, dan formulir pendaftaran atau pembayaran mengeluarkan kesalahan 403 pada pelanggan yang nyata — kemungkinan besar bukan hacker yang bersalah, tetapi WAF Anda sendiri. Firewall melihat ribuan permintaan dari satu alamat IP operator seluler dan menganggapnya sebagai DDoS atau brute force. Sebenarnya, di balik IP ini terdapat ratusan atau ribuan orang biasa — ini adalah teknologi CGNAT. Mari kita bahas bagaimana cara mendeteksi dan memperbaikinya, tanpa membuka celah untuk serangan yang nyata.
Apa itu CGNAT dan mengapa itu menjadi masalah
CGNAT (Carrier-Grade NAT) adalah teknologi yang digunakan oleh operator seluler karena kekurangan alamat IPv4. Alih-alih memberikan setiap pelanggan alamat IP publik yang unik, operator "menyembunyikan" ribuan pengguna di balik satu atau beberapa alamat bersama. Untuk situs web, ini terlihat seperti: dari satu IP datang lalu lintas dari ratusan orang yang berbeda secara bersamaan — perangkat yang berbeda, browser yang berbeda, perilaku yang berbeda, tetapi alamat eksternal yang sama.
Untuk server web biasa, ini bukan masalah — ia hanya memproses permintaan. Namun, untuk sistem perlindungan yang menghitung permintaan dalam satuan waktu dari satu IP, ini terlihat sebagai anomali. Bayangkan: dalam satu menit, dari satu alamat datang 200 permintaan ke halaman login. Untuk WAF, ini adalah pola klasik dari brute force atau scraping. Namun, sebenarnya ini bisa jadi 150 pelanggan nyata dari satu operator seluler di wilayah Anda yang hanya membuka situs secara bersamaan setelah pengiriman iklan atau publikasi di media sosial.
Masalah ini sangat terasa di negara-negara dengan kepadatan internet seluler yang tinggi — operator menggabungkan sejumlah besar pelanggan di bawah jumlah IP eksternal yang minimal. Itulah sebabnya menguji perilaku situs harus dilakukan bukan dari IP pusat data biasa, tetapi dari proxy seluler, yang benar-benar melewati infrastruktur CGNAT operator — hanya dengan cara ini Anda dapat mereproduksi gambaran yang sama yang dilihat WAF pada pengguna yang nyata.
Mengapa WAF melihat CGNAT sebagai ancaman
Sebagian besar solusi WAF — Cloudflare, AWS WAF, Imperva, modul bawaan Nginx/ModSecurity — menggunakan rate-limiting berdasarkan alamat IP sebagai mekanisme dasar perlindungan dari bot dan DDoS. Logika sederhana: jika dari satu IP lebih dari N permintaan dalam T detik — kita memblokir atau menampilkan captcha. Aturan ini bekerja dengan baik untuk serangan klasik dari satu perangkat, tetapi sepenuhnya rusak pada lalu lintas CGNAT.
Ada beberapa skenario tipikal di mana ini terjadi:
- Rate-limiting berdasarkan IP. Batas "100 permintaan per menit dari satu IP" — normal untuk lalu lintas pusat data, tetapi bencana bagi wilayah seluler dengan satu juta pelanggan di satu alamat.
- Peringkat perilaku. Jika sistem mengumpulkan "reputasi" IP berdasarkan riwayat permintaan, maka satu pengguna "buruk" di CGNAT dapat merusak reputasi alamat untuk ribuan pelanggan jujur yang berikutnya.
- Heuristik geografis. WAF kadang-kadang menandai IP sebagai mencurigakan jika melihat lonjakan aktivitas yang tajam, yang tidak biasa bagi pengguna "biasa" — dan perilaku alamat CGNAT memang seperti itu: beban puncak pada jam-jam aktivitas audiens.
- Blok berdasarkan ASN operator. Beberapa aturan WAF memblokir seluruh rentang ASN operator seluler, jika sebelumnya ada serangan dari rentang tersebut — semua pelanggan operator di negara tersebut terkena dampak.
Kesimpulannya: semakin ketat pengaturan WAF "dari pabrik", semakin tinggi kemungkinan bahwa ia memblokir bukan bot, tetapi audiens seluler nyata Anda — terutama jika bisnis Anda berorientasi pada negara-negara dengan internet seluler yang berkembang dan proporsi lalu lintas CGNAT yang tinggi.
Apa risikonya bagi bisnis: kehilangan pelanggan dan uang
Masalah pemblokiran CGNAT jarang terlihat dalam analitik standar. Google Analytics dan Yandex.Metrica tidak mencatat mereka yang menerima kesalahan 403 di tingkat WAF — kunjungan semacam itu sering kali bahkan tidak mencapai penghitung. Akibatnya, pemasar melihat penurunan konversi, tetapi tidak memahami penyebabnya, dan mulai mengoptimalkan kreatif dan halaman arahan, meskipun masalahnya ada di infrastruktur.
Konsekuensi nyata untuk berbagai segmen bisnis:
- E-commerce. Pembeli dari internet seluler tidak dapat menyelesaikan pemesanan — formulir pembayaran mengeluarkan kesalahan, keranjang hilang. Kerugian langsung dalam pendapatan, terutama terlihat setelah peluncuran iklan di TikTok Ads atau Facebook Ads, di mana lalu lintas utama adalah seluler.
- SaaS dan pendaftaran. Pengguna mencoba mendaftar atau masuk ke akun pribadi, menerima captcha di setiap langkah atau diblokir — beralih ke pesaing.
- Konten dan iklan. Lalu lintas iklan dari perangkat seluler secara massal "terputus" di landing page, anggaran iklan terbuang, tetapi konversi tidak ada — algoritma platform iklan menginterpretasikan ini sebagai kualitas audiens yang rendah dan meningkatkan biaya klik.
- Layanan dukungan. Jumlah permintaan "situs Anda tidak terbuka", "saya tidak bisa mendaftar" meningkat — tetapi dukungan teknis tidak melihat masalah, karena mereka sendiri mengakses dari desktop melalui Wi-Fi kantor tanpa CGNAT.
Yang paling tidak menyenangkan — pemblokiran semacam itu sulit didiagnosis setelah fakta, karena log WAF menunjukkan satu IP "mencurigakan" dengan jumlah permintaan yang sangat besar, dan administrator melihat ini sebagai konfirmasi kebenaran pemblokiran, bukan sebagai kesalahan palsu.
6 pemeriksaan dari IP seluler untuk menemukan masalah
Untuk memahami apakah WAF Anda memblokir pelanggan seluler yang jujur, Anda perlu mereproduksi kondisi nyata CGNAT — yaitu, menguji situs dengan IP seluler nyata dari berbagai operator dan wilayah. Berikut adalah daftar periksa praktis dari 6 pemeriksaan.
Pemeriksaan 1: Akses massal dari satu IP seluler
Atur beberapa sesi paralel melalui satu IP seluler yang sama (ini alami untuk proxy dengan CGNAT operator) dan lakukan 50-100 tindakan biasa — membuka halaman, menambahkan ke keranjang, berpindah antar bagian. Jika setelah ambang tertentu captcha atau 403 mulai muncul — ini adalah sinyal pertama masalah.
Pemeriksaan 2: Mengubah User-Agent pada satu IP
Satu alamat CGNAT melayani berbagai perangkat — iPhone, Android, berbagai browser. Jalankan permintaan dengan berbagai string User-Agent melalui satu IP dan periksa apakah aturan WAF "variabilitas perangkat yang mencurigakan dari satu alamat" diaktifkan.
Pemeriksaan 3: Uji pada formulir kritis
Ikuti seluruh jalur pelanggan — pendaftaran, otorisasi, penyelesaian pesanan, pembayaran — tepat melalui IP seluler operator. Seringkali WAF lebih agresif di formulir dengan input data (login, pembayaran), di mana risiko brute force lebih tinggi, dan ini adalah tempat pertama di mana pelanggan nyata hilang.
Pemeriksaan 4: Pemeriksaan dengan berbagai operator dan wilayah
Perilaku CGNAT berbeda antara operator dan negara — di satu tempat satu IP menyembunyikan 50 pelanggan, di tempat lain 5000. Uji situs dengan IP seluler dari beberapa operator di geo kunci untuk bisnis Anda, untuk memahami apakah ada spesifikasi regional dalam pemblokiran.
Pemeriksaan 5: Analisis respons server berdasarkan kode dan header
Catat tidak hanya fakta pemblokiran, tetapi juga kode HTTP yang tepat dan header respons (misalnya, cf-mitigated: challenge di Cloudflare). Ini akan membantu memahami mekanisme perlindungan mana yang diaktifkan — rate-limit, deteksi bot, atau aturan geografis.
Pemeriksaan 6: Pemantauan jangka panjang reputasi IP
Ulangi tes dari satu IP seluler yang sama selama beberapa hari. Jika akses memburuk seiring waktu tanpa alasan yang jelas dari pihak Anda — berarti sistem penilaian akumulatif "merusak" reputasi alamat karena aktivitas pelanggan lain di CGNAT yang sama, dan ini adalah masalah sistemik, bukan masalah sekali saja.
Penting untuk dipahami:
Untuk pengujian semacam ini, Anda memerlukan IP seluler yang nyata, bukan alamat pusat data atau alamat residensial biasa — hanya lalu lintas yang melewati infrastruktur operator yang benar-benar mereproduksi pola CGNAT yang dilihat WAF Anda pada pengguna yang nyata.
Cara mengatur WAF agar tidak memblokir pelanggan yang jujur
Setelah diagnosis, perlu untuk menyesuaikan aturan perlindungan sehingga tidak kehilangan tingkat keamanan, tetapi berhenti memblokir pengguna seluler yang nyata. Berikut adalah pendekatan utama.
| Masalah | Solusi di WAF |
|---|---|
| Rate-limit yang ketat berdasarkan IP | Tingkatkan batas untuk ASN operator seluler yang dikenal atau beralih ke batas berdasarkan sesi/kuki daripada hanya IP murni |
| Peringkat reputasi IP yang akumulatif | Kurangi waktu "memori" reputasi untuk rentang CGNAT, tambahkan whitelist untuk ASN operator yang dikenal |
| Blok berdasarkan geo/ASN secara keseluruhan | Ganti pemblokiran total dengan tantangan lembut (pemeriksaan JS) daripada 403 |
| Captcha yang ketat pada formulir login | Aktifkan captcha secara adaptif — hanya saat ada tanda-tanda nyata dari brute force (beberapa upaya gagal dari satu akun), bukan hanya berdasarkan IP CGNAT |
Praktik yang baik adalah menjaga daftar sendiri dari rentang operator seluler yang dikenal di geo kunci Anda dan memberikan aturan yang lebih lembut dibandingkan dengan lalu lintas internet biasa. Ini membutuhkan waktu untuk pengaturan, tetapi secara drastis mengurangi jumlah pemblokiran palsu.
Alat untuk pengujian dengan proxy seluler
Untuk audit perlindungan situs secara teratur, nyaman menggunakan kombinasi dari browser anti-detect dan proxy seluler. Browser anti-detect (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) memungkinkan Anda membuat profil terisolasi dengan berbagai sidik jari perangkat, sementara proxy seluler menyediakan lalu lintas CGNAT yang nyata dari operator.
Pendekatan langkah demi langkah untuk pengujian:
- Buat beberapa profil di browser anti-detect dengan parameter perangkat yang berbeda (User-Agent yang berbeda, resolusi layar, zona waktu).
- Hubungkan ke setiap profil proxy seluler dari wilayah dan operator yang diperlukan — ini akan memberikan perilaku CGNAT yang nyata.
- Ikuti skenario pengguna kunci: pendaftaran, login, menambahkan ke keranjang, pembayaran.
- Catat semua kasus captcha, 403, dan pemblokiran lainnya, dan bandingkan dengan pengaturan WAF.
- Ulangi tes melalui proxy residensial untuk perbandingan — ini akan membantu memahami apakah masalah ini spesifik untuk lalu lintas seluler.
Untuk pengujian paralel di berbagai geo, proxy residensial juga berguna — mereka membantu menilai seberapa agresif WAF untuk lalu lintas rumah biasa dan CGNAT seluler. Jika Anda berencana melakukan pengujian beban dari infrastruktur server tanpa keterikatan pada operator, untuk pemeriksaan kontrol tanpa efek CGNAT, Anda dapat menghubungkan proxy pusat data — ini akan memberikan garis dasar yang bersih tanpa distorsi yang khas dari jaringan seluler.
Pendekatan komprehensif ini — IP seluler, residensial, dan pusat data dalam satu tes — memberikan gambaran lengkap: Anda dapat melihat dengan jelas di mana perlindungan diaktifkan dan untuk jenis lalu lintas mana, dan tidak hanya menebak berdasarkan petunjuk tidak langsung di log.
Pertanyaan yang Sering Diajukan
Bisakah rentang CGNAT sepenuhnya dikecualikan dari aturan WAF?
Tidak disarankan — ini akan mengurangi perlindungan dari serangan nyata, yang juga dapat datang melalui jaringan seluler. Lebih baik untuk melunakkan ambang batas dan beralih ke tantangan lembut daripada pemblokiran yang ketat.
Seberapa sering perlu melakukan pemeriksaan semacam ini?
Minimal sebulan sekali dan pasti setelah setiap perubahan aturan WAF atau peluncuran kampanye iklan baru untuk audiens seluler.
Apakah ini mempengaruhi SEO?
Ya — jika bot pencari atau pengguna nyata dari perangkat seluler menerima 403, ini meningkatkan tingkat pentalan dan dapat berdampak negatif pada metrik perilaku peringkat.
Kesimpulan
CGNAT bukanlah ancaman, tetapi merupakan fitur dari internet seluler yang dihadapi hampir setiap bisnis dengan audiens seluler. Masalahnya bukan pada teknologi itu sendiri, tetapi pada pengaturan standar WAF yang pada awalnya tidak mempertimbangkan spesifikasinya dan menghukum pengguna yang jujur karena perilaku yang khas dari jaringan seluler biasa. Enam pemeriksaan dari artikel ini akan membantu dengan cepat mendiagnosis apakah Anda kehilangan pelanggan karena pemblokiran palsu, dan penyesuaian aturan WAF yang tepat dapat mengembalikan konversi tanpa mengurangi tingkat perlindungan.
Jika Anda berencana untuk secara teratur menguji perilaku situs dan saluran iklan seperti yang dilihat oleh pelanggan seluler yang nyata, kami merekomendasikan menggunakan proxy seluler — mereka memberikan lalu lintas CGNAT yang sebenarnya dari operator dan memungkinkan Anda menemukan pemblokiran palsu sebelum pelanggan Anda menemukannya.