Как определить ASN по IP-адресу: IPv4, IPv6 и журналы

Когда пригодится поиск ASN по адресу

• Уточнить сеть назначения при необычном росте исходящих соединений.
• Добавить сетевой контекст к событиям входа, WAF и VPN.
• Передать провайдеру адреса и время проблемного соединения.
• Проверить, не принадлежит ли наблюдаемый адрес промежуточному прокси или облачной площадке.
• Сравнить адреса до и после переноса сервиса, сохранив дату каждого результата.

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

Шаг 1. Возьмите из журнала именно IP-адрес

Сначала уточните, что означает поле: источник или назначение, адрес до NAT или после него, сетевой участник соединения или значение HTTP-заголовка. Иначе сервис правильно найдёт сеть адреса, который не относится к вашему вопросу.

1. Сохраните исходное событие, время и часовой пояс.
2. Скопируйте один адрес без лишних символов.
3. Для IPv4 удалите порт: из 1.1.1.1:443 нужен только 1.1.1.1.
4. Для IPv6 берите адрес из отдельного поля журнала. В записи [2606:4700:4700::1111]:443 скобки и порт не являются частью IP.
5. Не вводите URL, доменное имя, маску сети или список адресов.

Нельзя просто отрезать IPv6 по последнему двоеточию: двоеточия входят в сам адрес. Если журнал хранит IP и порт раздельно, используйте эти поля. Для доменного имени сначала нужен DNS-результат на нужный момент; один домен может указывать на несколько IPv4 и IPv6.

Шаг 2. Найдите ASN публичного IPv4

1. Откройте сервис ASN по IP.
2. В поле «IP-адрес» введите 1.1.1.1.
3. Нажмите «Определить ASN →».
4. Прочитайте результат и дату источника.

В проверенном примере получены AS13335, CLOUDFLARENET - Cloudflare, Inc., диапазон 1.1.1.0–1.1.1.255, код страны US. Это публичный адрес DNS-резолвера из документации Cloudflare; пример не является признаком атаки.

По ссылке AS13335 можно перейти к сведениям об автономной системе. Если изначально известен номер или название, удобнее использовать отдельный справочник ASN. Поиск номера и определение сети конкретного IP — разные операции.

Шаг 3. Проверьте публичный IPv6

В том же поле введите 2606:4700:4700::1111 и повторите проверку. Это другой публичный адрес того же резолвера, опубликованный Cloudflare. При подготовке сервис также вернул AS13335 и описание Cloudflare.

Диапазон в результате: 2606:4700:4700:: — 2606:4700:4700:ffff:ffff:ffff:ffff:ffff. Границы соответствуют /48. Такое представление удобнее для понимания интервала, но не доказывает, что каждый его адрес используется или что весь блок объявлен единственным маршрутом.

Если приложение пишет IPv4-mapped IPv6 вида ::ffff:1.1.1.1, этот сервис такую форму не проверяет. При тесте он показал отказ для IPv4-mapped адресов. Выделяйте исходный IPv4 только когда формат поля и его смысл подтверждены; произвольное преобразование строк может скрыть ошибку журнала.

Как правильно читать результат

Диапазон IPv4 нашего примера содержит 256 адресов, включая обе границы. Это не «254 доступных абонента»: здесь считается интервал базы, а не число устройств в локальной подсети. Не оценивайте размер организации или число клиентов по количеству адресов в одной строке.

Почему 192.168.1.1 не получает публичный ASN

Сервис предназначен для публичных адресов. При вводе 192.168.1.1 мы получили «Проверка не выполнена» и пояснение о локальных, служебных и IPv4-mapped адресах. Это ожидаемая граница проверки, а не сбой вашего роутера.

Назначение специальных блоков проверяют по реестрам IANA IPv4 и IANA IPv6. Блок 100.64.0.0/10 выделен отдельно от частного пространства RFC 1918; его назначение описано в RFC 6598.

Не все адреса на 172.* являются частными: частный блок ограничен 172.16.0.0/12. И наоборот, корректный синтаксис адреса ещё не означает, что он глобально маршрутизируется.

Ошибка ввода и отсутствие записи — разные состояния

Для 999.1.1.1 сервис показал «Введите IPv4 или IPv6 без протокола, порта и маски». Исправление здесь — получить корректный адрес, а не искать другого провайдера. Формат нужно проверить до интерпретации результата.

• Неверный формат: проверьте октеты, скобки, порт, маску и лишние символы.
• Локальный или служебный адрес: ищите его в своей схеме сети и журналах.
• Соответствие не найдено: адрес может отсутствовать в снимке или не иметь нужной записи в источнике.
• Техническая ошибка: повторите запрос позже и зафиксируйте сообщение; не превращайте её в вывод об адресе.

Если сервис не нашёл ASN, это не подтверждает, что IP свободен, безопасен, не зарегистрирован или обязательно не маршрутизируется.

Дата события важнее уверенного названия сети

В сервисе используется локальный снимок IPtoASN. Источник публикует соответствия диапазонов, ASN, кода страны и описания. Это не сеанс BGP и не полный реестр выданных ресурсов.

На дату подготовки был показан снимок от 1 ноября 2026 года, 16:38 НСК, с предупреждением о возрасте больше семи дней. Такой результат нужно записывать как «по снимку от …». Актуальность исходного проекта не гарантирует ту же частоту обновления локальной копии.

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

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

Независимая сверка: пример RIPEstat и PowerShell

Мы дополнительно запросили Network Info RIPEstat. Этот интерфейс возвращает содержащий IP префикс и объявляющие ASN по данным RIPE RIS. Для 1.1.1.1 получены ASN 13335 и 1.1.1.0/24; для IPv6 — ASN 13335 и 2606:4700:4700::/48. В этих двух примерах результаты согласуются с диапазонами сервиса.

Повторить чтение можно в PowerShell. В отличие от поиска по локальной базе AVG IT этот запрос передаёт проверяемый IP внешнему сервису RIPEstat. Используйте разрешённые вашей компанией источники проверки. Синтаксис Invoke-RestMethod описан Microsoft.

IPv4

(Invoke-RestMethod -Uri 'https://stat.ripe.net/data/network-info/data.json?resource=1.1.1.1').data

Команда отправляет HTTPS-запрос и выводит объект data из JSON. Смотрите поля asns и prefix. Она не изменяет настройки и не проверяет доступность 1.1.1.1 по DNS или другому протоколу.

IPv6

(Invoke-RestMethod -Uri 'https://stat.ripe.net/data/network-info/data.json?resource=2606%3A4700%3A4700%3A%3A1111').data

Здесь адрес закодирован в параметре URL. При подготовке ответ содержал /48 и AS13335. Сохраняйте полный ответ, время и метаданные источника. Совпадение двух примеров не доказывает, что любой интервал базы всегда равен одному BGP-префиксу.

Прикладной пример: выросло число соединений к DNS

Условная ситуация: мониторинг показывает рост исходящих соединений, firewall часто фиксирует назначение 1.1.1.1. Поиск даёт AS13335 и Cloudflare. Это объясняет сетевую принадлежность назначения, но не причину нагрузки. Сам адрес известного резолвера не является доказательством вредоносной активности.

1. Проверьте направление, протокол и порт. DNS, HTTPS и соединения другого назначения нельзя объединять только по IP.
2. Найдите внутренний источник до NAT и время всплеска.
3. Сопоставьте DHCP, VPN или данные агента с конкретным устройством на этот момент.
4. Уточните процесс, расписание задач и настройки приложения.
5. Сравните событие с нагрузкой CPU, сети, ошибками и изменениями конфигурации.
6. После устранения причины повторите тот же сценарий и проверьте рабочие функции.

1. Событие: время, направление, IP и порт.
2. Контекст сети: ASN и дата источника.
3. Локальный контекст: NAT, устройство, процесс.
4. Проверка: причина, действие и результат.

Если расследуется входящий запрос, порядок похож: сначала сетевой источник и доверенная цепочка прокси, затем приложение, учётная запись и действие. Название оператора не заменяет эти этапы.

Прокси, CDN и VPN: чей адрес попал в журнал

Веб-сервер за обратным прокси обычно принимает соединение от прокси. Его сетевой адрес может принадлежать CDN или облачной AS, хотя исходный пользователь находится в другой сети. У VPN и корпоративного шлюза наружу также может выходить множество устройств под одним адресом.

Клиент → прокси: прокси видит адрес своего сетевого собеседника.

Прокси → приложение: приложение может видеть адрес прокси.

Исходный IP: брать только из проверенной доверенной цепочки.

Не считать любой внешний HTTP-заголовок доказательством адреса клиента.

Для восстановления исходного IP используют документированные заголовки и настройки доверенных прокси. Например, Cloudflare описывает CF-Connecting-IP и X-Forwarded-For. Учитывайте особенности конкретной схемы, ограничьте доверие к известным узлам и не позволяйте прямому внешнему запросу подставить «доверенный» заголовок.

Если журнал хранит только адрес прокси, поиск ASN покажет его сеть. Перед выводами проверьте, какое поле логируется и кто его сформировал. Не подменяйте исходный сетевой адрес непроверенной строкой из запроса.

NAT и динамические адреса: почему ASN не находит сотрудника

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

И обратная ситуация: одно устройство меняет адрес при переподключении или использует разные IPv6-адреса. Сравнение названия AS без временной привязки не связывает события с человеком. Устройство, учётная запись и действие подтверждаются своими источниками.

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

ASN полезен для группировки и приоритизации расследования. Он не заменяет учёт доступа, аутентификацию и анализ действий пользователя.

Какие действия нельзя обосновать одним ASN

• Объявить IP безопасным. Известная сеть может обслуживать разных клиентов и сценарии.
• Назвать человека или точный адрес. Сетевая запись этого не раскрывает.
• Заблокировать всю AS без оценки. Можно затронуть легитимные облачные сервисы, API и пользователей.
• Выдать административный доступ. Нужны конкретный сценарий, идентичность, минимальные права и срок.
• Считать адрес свободным. Отсутствие соответствия не является подтверждением свободы ресурса.

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

Короткий порядок проверки для администратора

1. Зафиксировать событие с исходным IP, временем, портами и направлением.
2. Определить точку наблюдения, NAT, прокси и VPN.
3. Проверить синтаксис и назначение адреса.
4. Выполнить поиск и сохранить ASN, описание, диапазон и дату базы.
5. При необходимости перепроверить соответствие подходящим независимым источником.
6. Связать событие с устройством, процессом и действием по доверенным журналам.
7. Отдельно сформулировать подтверждённое, предположения и недостающие данные.
8. Проверить результат принятой меры на рабочем сценарии.

Правильная запись в отчёте: «По снимку IPtoASN от такой-то даты IP связан с AS…». Утверждения о причине инцидента и личности требуют дополнительных подтверждений. На подготовленных примерах выполнены поиск и независимая сверка; реальный инцидент, доступность узлов и работа приложений здесь не испытывались.

Материалы для проверки и расследования

Начните с определения ASN по IP. Для изучения номера и диапазонов используйте справочник автономных систем, для доменных записей — проверку DNS и почты.

Поможем связать сетевые события с работой бизнеса

Частые вопросы