Локальный, публичный и адрес прокси — три разных IP

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

Адрес 192.168.x.x описывает устройство внутри локальной сети, внешний адрес выдаёт провайдер или VPN, а выходной адрес прокси видит целевой сайт. Эти значения совпадают только в отдельных схемах.

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

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

На учебных адресах показываем, какой IP нужен для подключения и какой — для белого списка.

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

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

На одном компьютере выпишите адрес сетевого интерфейса, адрес шлюза, внешний адрес прямого выхода, endpoint прокси и выходной адрес через прокси. Используйте сервис на своём сервере, который возвращает remote address. Затем попробуйте добавить в белый список учебный 192.168.x.x: внешний прокси его не увидит, потому что частный адрес не маршрутизируется через интернет.

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

Для белого списка откройте контрольный endpoint с того сервера, который будет подключаться, и внесите его публичный исходящий IPv4. Для строки прокси используйте адрес сервиса и порт; внутренний адрес ноутбука туда не подходит.

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

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

• Записать адрес интерфейса
• Определить прямой внешний IP
• Отметить endpoint прокси
• Проверить выход через свой сервер

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

Таблица должна содержать назначение каждого адреса и способ получения. Полные рабочие реквизиты скрывайте; для endpoint достаточно маски и внутреннего ID. Отдельно фиксируйте IPv4 и IPv6, поскольку сайт может видеть разные семейства.

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

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

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

Публичный адрес может меняться или быть общим из-за NAT. Передавать доступ по широкому CIDR следует только после подтверждения владельца диапазона.

VPN, CGNAT и корпоративный NAT добавляют новые уровни. Команда ipconfig показывает локальный интерфейс, но не гарантирует адрес, который увидит удалённый сервис.

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

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

Для «Локальный, публичный и адрес прокси — три разных 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 указаны отдельно
• Сравнены прямой и прокси-выход
• Учтена дата геобазы
• Город не трактуется как точный адрес
• Проверена совместимость клиента