Как проверить белый IP или нет: адрес за NAT, записи whois и списки репутации

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

Белый и серый адрес: где проходит граница

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

Диапазон 100.64.0.0/10 стоит запомнить отдельно. Он выглядит непривычно, многие принимают его за публичный и потом полдня ищут, почему проброс порта не работает. Я видел это на трёх разных площадках подряд: администратор смотрит на адрес, не узнаёт его, считает белым и строит на этом всю схему. Проверка занимает секунды, а разбор последствий растягивается на дни.

Минутная проверка: адрес интерфейса и адрес на выходе

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

# адрес интерфейса
ip -4 addr show scope global        # Linux
ipconfig                            # Windows

# адрес на выходе
curl -s https://api.ipify.org
curl -s https://ifconfig.me/ip

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

ip route get 1.1.1.1
route print 0.0.0.0                 # Windows

Вывод показывает интерфейс, шлюз и исходящий адрес одной строкой. Этого достаточно, чтобы понять, какой из адресов узла попадёт в заголовки исходящего запроса. Ещё я держу в уме одну тонкость: сервисы определения внешнего адреса отвечают по IPv4 и по IPv6 по-разному. Если у узла поднят IPv6 и он предпочтителен по умолчанию, curl вернёт шестую версию, а вся дальнейшая диагностика по спискам и реестрам построена вокруг четвёртой. Поэтому запрос я делаю с явным флагом версии: curl -4 -s https://api.ipify.org. Один этот флаг снимает регулярную путаницу, когда локальные утилиты показывают одно, а площадка видит совсем другой адрес.

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

Адрес за NAT и адрес, выданный узлу напрямую

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

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

# на проверяемом узле
nc -l -p 8443

# со стороннего узла
nc -vz 203.0.113.10 8443
timeout 3 bash -c '</dev/tcp/203.0.113.10/8443' && echo port open

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

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

Четыре источника данных об одном адресе

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

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

Что показывает whois и как читать его поля

Запрос в реестр возвращает запись о диапазоне, в который попал адрес. Ключевых полей там немного, и читаются они быстро.

whois 203.0.113.10
whois -h whois.ripe.net 203.0.113.10

Смотрю на inetnum: он показывает границы блока. Блок в /29 или /28 означает, что диапазон нарезан под конкретного абонента. Блок в /19 и шире означает крупный пул, внутри которого адреса раздаются десяткам разных клиентов. Поле netname часто содержит осмысленное имя вроде HOSTING-CUST-14, и по нему видно назначение блока. Поле status разделяет выделения: ASSIGNED PA говорит, что адреса выданы оператором из своего агрегата, ASSIGNED PI говорит о независимом выделении. Поле descr и организация в org дают владельца, а abuse-c даёт адрес для жалоб, по которому легко понять, кто разбирает инциденты.

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

Запись rDNS: имя, которое видит принимающая сторона

Обратная зона хранит имя, которое владелец подсети повесил на адрес. Принимающие серверы запрашивают её при каждом входящем соединении, и по имени они делают первые выводы о типе узла.

dig -x 203.0.113.10 +short
nslookup 203.0.113.10

Имена вида node10.dc3.example-hosting.net говорят о размещении в стойке. Имена вида 203-0-113-10.pool.example-isp.net, где адрес закодирован прямо в строке, говорят о динамической выдаче из общего пула. Пустой ответ говорит, что запись не заведена, и почтовые серверы такое соединение принимают неохотно. У меня есть привычка: перед тем как поднимать что-то с исходящей почтой, я проверяю прямое и обратное соответствие, то есть чтобы имя из обратной зоны резолвилось обратно в тот же адрес.

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

База принадлежности подсети: номер AS и маршрут

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

whois -h whois.cymru.com " -v 203.0.113.10"

Ответ содержит номер автономной системы, префикс, который реально анонсируется, страну и имя оператора. Длина префикса в ответе часто расходится с inetnum из реестра: реестр отдаёт /24, маршрут показывает /22, и это нормально для агрегированных анонсов. Меня в этом ответе интересуют две вещи: тип оператора и стабильность анонса. Транзитные и хостинговые автономные системы площадки распознают уверенно, и часть проверок отрабатывает уже на этом уровне, до всякого анализа поведения.

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

Статический или динамический: как отличить и как получить постоянный

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

ipconfig /all | findstr /C:"Lease"      # Windows
cat /var/lib/dhcp/dhclient.leases       # Linux
nmcli -f IP4 device show eth0

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

Запрос «как сменить динамический ip на статический» звучит так, будто речь о настройке. Настройками режим выдачи не переключается: постоянный адрес даёт тот, кто владеет подсетью. Практически это делается двумя путями. Первый: заказать у оператора связи постоянный адрес на линию, если такая опция есть в тарифе. Второй: взять доступ к серверному пулу, где адреса изначально выданы узлам целиком, и работать через него. Второй путь я использую чаще, потому что он даёт предсказуемый результат в тот же день и не зависит от возможностей местной линии. Когда нужен постоянный выход на длительный срок, подходит месячный срок доступа к пулу с продлением без перерыва, а если требуется собственный пул под несколько узлов, я иду купить прокси IPv4 нужным объёмом и распределяю адреса по узлам заранее.

Публичные списки репутации: как читать выдачу

Списки репутации работают через обычные DNS-запросы. Адрес разворачивается задом наперёд, к нему приписывается зона списка, и по наличию A-записи определяется, есть ли отметка.

# адрес 203.0.113.10 в обратном порядке
dig +short 10.113.0.203.zen.spamhaus.org
dig +short 10.113.0.203.bl.spamcop.net
dig +short -t TXT 10.113.0.203.zen.spamhaus.org

Пустой ответ означает отсутствие записи в этой зоне. Ответ вида 127.0.0.x означает отметку, и последний октет кодирует, какой именно подсписок сработал: отдельные коды отведены под рассылки, отдельные под заражённые узлы, отдельные под диапазоны, которые владелец сам пометил как непригодные для прямой отправки почты. Запрос TXT возвращает пояснение и ссылку на страницу удаления. Смотрю я на дату записи и на причину: отметка полугодовой давности от прошлого арендатора и свежая отметка от вчерашней рассылки означают совершенно разные вещи.

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

IP=203.0.113.10
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
for z in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org dnsbl.sorbs.net; do
  printf '%-28s %s\n' "$z" "$(dig +short $REV.$z | head -1 || echo -)"
done

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

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

Отдельная категория списков закрывает веб-формы: там собираются адреса, замеченные на переборе паролей и на массовой отправке форм. Их выдача обычно доступна через простой запрос по HTTP и содержит счётчик, категорию и дату последнего сообщения. Смотрю я туда, когда адрес планируется под работу с сайтами, где есть авторизация. По почтовым спискам такой адрес может быть без единой отметки, при этом веб-списки покажут плотную историю, и наоборот. Зоны наполняются разными людьми под разные задачи, поэтому пропускать половину проверки смысла нет.

Почему сервисы расходятся в оценке и что видят площадки

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

Первая причина: разная частота обновления. Маршрутная информация обновляется за минуты, реестры за дни, геобазы за недели, а коммерческие базы типов подсетей иногда за месяцы. Вторая причина: разные наборы источников. Один сервис опирается на записи реестра, второй на собственные наблюдения за трафиком, третий покупает готовую базу у поставщика. Третья причина: собственные оценочные шкалы. Часть сервисов выводит балл, собранный из десятка признаков с весами, которые нигде не опубликованы, и сравнивать такие баллы между собой бессмысленно. Четвёртая причина: кэш на стороне самого сервиса, который отдаёт результат недельной давности без всякой пометки.

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

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

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

Дальше по теме основ полезны разборы выбора между IPv4 и IPv6, настройки порта прокси-сервера и месячного пакета доступа, которые дополняют картину по адресу с другой стороны. Из раздела сбора данных к этой теме ближе всего разбор капчи при сборе данных: там видно, как признаки адреса превращаются в дополнительные проверки на входе.