CGNAT: почему один внешний IP бывает у многих абонентов

Основная идея

CGNAT позволяет оператору размещать многих абонентов за одним публичным IPv4; внутри сети часто используются адреса 100.64.0.0/10. Поэтому совпавший внешний IP не доказывает, что запросы сделал один человек или одно устройство.

Статья «CGNAT: почему один внешний IP бывает у многих абонентов» требует различать интерфейс устройства, адрес домашнего маршрутизатора, адрес прокси, выходной IP, ASN и географическую оценку. Эти значения относятся к разным точкам сети. База геолокации может показывать центр региона или узел оператора, поэтому её ответ нельзя превращать в точный физический адрес человека.

Что подтверждает первичный источник

Объясняем общие адреса мобильных сетей и почему внешний IP не идентифицирует одного человека.

Первичный источник «RFC 6598» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

На тестовом мобильном подключении сравните адрес интерфейса, адрес в диапазоне 100.64.0.0/10 при его наличии и внешний адрес контрольного сайта. Переподключите сеть несколько раз с паузой и посмотрите, меняется ли внешний шлюз. Не пытайтесь искать другого абонента: задача лишь показать, что NAT оператора отображает общий публичный адрес для множества внутренних сессий.

Проверка шаг за шагом

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

Нарисуйте маршрут от клиента до контрольного endpoint и подпишите, где выполняются DNS, NAT и проксирование. Затем соберите прямой результат и результат через прокси: семейство IP, выходной адрес, ASN, заявленный регион и время. Для мобильной сети повторите несколько раз, поскольку оператор может менять шлюз без изменения физического положения устройства.

Сравнивайте не один сервис геолокации, а заявленную географию продукта, фактический ASN и как минимум две независимые базы. Расхождение города при совпадении страны и оператора часто укладывается в точность базы. Если приложению нужна строгая страна, проверяйте её перед рабочей сессией; если нужен точный GPS, IP для этого непригоден.

• Проверить диапазон интерфейса
• Снять внешний IP
• Повторить после переподключения
• Сопоставить ASN оператора

Какие данные сохранить

Запишите время, тип сети, внутренний адрес, внешний IP и факт переподключения. Не используйте IP как идентификатор личности. Для поддержки полезнее ASN, оператор и временной интервал, чем предположение о конкретном устройстве.

Записывайте маскированный IP или внутренний идентификатор, семейство адреса, ASN, организацию, тип сети, базу и дату её обновления. Для спора полезны результаты в один момент времени. Не сохраняйте лишние координаты и не публикуйте полные реквизиты прокси: сетевой отчёт должен объяснять классификацию, не становясь списком доступов.

Сразу задайте имена колонок отчёта и формат времени. Результат без контекста быстро превращается в догадку: неизвестно, какой адрес использовался, был ли кэш и что изменилось. Сохраняйте не только успех, но и контролируемые отказы. Они доказывают, что проверка действительно различает состояния, а не всегда рисует зелёный индикатор.

Как читать результат

Геолокация общего адреса может указывать на узел оператора в соседнем городе. Это нормальное ограничение маршрутизации и баз IP, а не точные координаты абонента.

Наличие общего адреса не доказывает использование коммерческого прокси. CGNAT — функция сети оператора, а одинаковый внешний IP у двух наблюдений не означает одного пользователя.

Один успешный запуск подтверждает только конкретную комбинацию клиента, маршрута и времени. Для устойчивого вывода повторите опыт, изменяя одну переменную, и укажите границы. Если наблюдение расходится с документацией, сначала исключите кэш, версию программы и промежуточный сервер, а затем сформулируйте воспроизводимый пример для поддержки.

Разбор рабочего решения

Для «CGNAT: почему один внешний IP бывает у многих абонентов» нарисуйте маршрут с реальными ролями, но обезличенными адресами: устройство, шлюз, публичный NAT, вход прокси, выход прокси, DNS и конечный сервер. Рядом подпишите семейство IPv4/IPv6 и точку, в которой измеряется каждый адрес. Такая схема предотвращает типичную ошибку, когда локальный 192.168.x.x пытаются добавить в удалённый белый список или входной сервер принимают за географию выхода.

Сопоставляйте географию минимум с ASN и временем наблюдения. Базы обновляются не одновременно, мобильные сети используют общие шлюзы, а anycast может направлять запрос к разным узлам. Расхождение города само по себе не доказывает неисправность. Для строгого требования сначала подтвердите страну на контрольном endpoint, затем выполните прикладной запрос и сохраните выходной IP именно этой сессии.

При проблеме проверяйте маршрут слоями: локальный DNS и таблицу маршрутов, соединение до входа прокси, авторизацию, выходное семейство адреса и достижимость назначения. Ping не проверяет HTTP CONNECT и может быть запрещён при рабочем TCP. Используйте инструмент, соответствующий протоколу приложения. После изменения повторите исходный малый сценарий, а не новый тест с другими адресом, DNS и сайтом.

Типичные ошибки

Частые ошибки — добавлять 192.168.x.x в белый список внешнего сервиса, путать CGNAT с прокси и считать название ISP гарантией мобильного устройства. Также программы по-разному обрабатывают IPv6 и DNS. Проверяйте весь путь конкретным клиентом и отделяйте несовместимость формата от недоступности сети.

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

Критерии внедрения и сопровождение

Перед внедрением сформулируйте критерий решения: какое наблюдение разрешает продолжить работу, какое требует ручной проверки, а какое немедленно останавливает процесс. Укажите допустимый процент ошибок, максимальное время ожидания и владельца исключения. Без этих границ команда начинает объяснять одинаковый результат по-разному, а временный сбой незаметно превращается в постоянную настройку.

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

Рабочий регламент

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

• Подписаны все адреса маршрута
• DNS и NAT указаны отдельно
• Сравнены прямой и прокси-выход
• Учтена дата геобазы
• Город не трактуется как точный адрес
• Проверена совместимость клиента