CGNAT простыми словами: почему один IP-адрес — это не один пользователь

Удивительно много антифрод-правил до сих пор держится на предположении, которое уже давно не работает: будто IP-адрес однозначно указывает на пользователя. Главная причина, почему это не так, — Carrier-grade NAT, или CGNAT.

Что такое CGNAT

IPv4-адреса закончились. Вместо того чтобы покупать дефицитные адресные блоки под каждого абонента, мобильные операторы и многие фиксированные провайдеры помещают клиентов за общий пул публичных адресов, а на выходе транслируют порты. В результате за одним публичным адресом могут одновременно находиться сотни или тысячи квартир, домов и смартфонов.

Для вашего сервера весь этот трафик выглядит как один клиент.

Что из-за этого ломается

Блокировки. Заблокировали адрес после попытки брутфорса — и вместе с атакующим могли отрезать от сервиса целый район в мобильной сети. Атакующий переподключится, за несколько секунд получит другой адрес из пула и продолжит.

Rate limiting. Лимит в 10 запросов в минуту на IP выглядит щедрым для одного человека и совершенно непригодным для 2 000 абонентов, которые делят один выходной адрес. В часы пик вы будете душить легитимных пользователей и, скорее всего, даже не заметите этого: они просто уйдут.

Атрибуция. «Два аккаунта с одного IP» — слабый аргумент в пользу мультиаккаунтинга, если речь о сети оператора. На домашнем оптоволокне такой сигнал может что-то значить. За CGNAT — почти ничего.

Аналитика. Подсчет уникальных посетителей по IP занижает аудиторию в мобильных сетях и завышает ее там, где адреса часто ротируются. Обе ошибки обычно тихо прячутся в дашборде.

Как понять, что перед вами CGNAT

Сигналы, на которые стоит обратить внимание:

• Тип подключения определяется как mobile, либо ASN принадлежит мобильному оператору.
• С одного адреса идет очень разнородный трафик: много user agent, много аккаунтов, много географий и локалей.
• В forwarded headers встречаются адреса из shared-transition space (100.64.0.0/10).

IP intelligence lookup напрямую дает первые два признака — этого уже достаточно, чтобы менять политику обработки запроса на лету.

Что делать вместо этого

• Масштабируйте лимиты по классу сети. Для residential-сетей можно держать жесткий per-IP лимит. Для мобильных и бизнес-диапазонов лимит по IP должен быть заметно мягче, а компенсировать это стоит более строгими ограничениями по аккаунту и устройству.
• Смещайте идентичность на уровень ниже. Где возможно, ограничивайте по account ID, сессии или device signal. Используйте IP как вторичный ключ, а не как главный идентификатор.
• Предпочитайте challenge вместо блокировки. Challenge создает неудобство для общей сети; блокировка наказывает всех ее пользователей сразу.
• Ставьте короткий срок жизни. Если общий адрес все-таки нужно заблокировать, считайте время минутами, а не днями. Атакующий уйдет гораздо раньше, чем закончится длинный бан.
• Следите за масштабом побочного ущерба. Если одна блокировка затрагивает больше чем несколько активных аккаунтов, это признак shared address — и, скорее всего, блокировка здесь не тот инструмент.

Главный принцип

IP-адрес описывает маршрут, а не человека. Это сильный risk signal, но плохой идентификатор. Системы, которые учитывают эту разницу, блокируют гораздо больше злоупотреблений на одно ложное срабатывание, чем системы, которые ее игнорируют. И даже распространение IPv6, частично возвращающее адресацию на уровне отдельного абонента, не решит проблему полностью, пока доля мобильного трафика продолжает расти.