Шлюз или переадресованный клиент? Как читать адрес источника

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

Что на самом деле видит назначение

Возьмите клиента по адресу 10.20.0.7, шлюз с внешним адресом 198.51.100.10 и назначение в интернете. Если шлюз транслирует источник клиента, сокет назначения записывает 198.51.100.10. Частный адрес исчезает из пакета, и назначение не может прочитать его обратно из этого заголовка. Эти числа иллюстративны, а не запись из вашей сети.

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

Состояние трансляции не видно назначению

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

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

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL и отпечатки — это подсказки, а не доказательства

TTL в IPv4 зависит от начального значения, выбранного отправителем, и от числа переходов, которые прошёл пакет. Без обоих фактов значение не может доказать, что произошёл переход VPN. Известный дополнительный маршрутизируемый переход тоже не позволяет отличить маршрутизатор LAN, путь туннеля или иную схему пересылки. Относитесь к разнице TTL как к вопросу, а не выводу.

Другие сигналы ведут себя так же. Заголовок User-Agent может задать приложение, а сходство по времени может отражать общую инфраструктуру, а не общего человека. Несколько пользователей могут делить один выход, и один пользователь может менять путь между сеансами. Собранные вместе, несколько слабых сигналов могут оправдать более пристальный взгляд на записи шлюза, но от накопления они не становятся сильными доказательствами.

Авторизуйте по идентичности, а не по адресу

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

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

Запишите дату наблюдения и систему, которая его создала. Фрагмент журнала без атрибуции трудно защитить позже.