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

Строка журнала показывает один адрес. Ноутбук несёт адрес туннеля, соединение может выходить через другую точку выхода, а проверка в браузере, которую вы сделали, ничего не говорит о FTP. Все три могут различаться, а строка журнала фиксирует только один из них. Прежде чем что-либо сравнивать, решите, о каком соединении вы спрашиваете.

Эти шаги предполагают санкционированное расследование с заданным временным окном, а не прогулку по чужим передачам.

1. Определите, о каком соединении идёт речь

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

У этого разделения есть практическое следствие. Строка входа и строка передачи из одной сессии могут нести два разных адреса источника, так что цитировать любую из них как «адрес клиента» — это догадка о том, какое соединение вы читаете. Проверяйте тип события, прежде чем сопоставлять адрес с чем-либо.

2. Проследите соединение управления

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

Если клиент обходит туннель, сервер видит адрес доступа, а собственный адрес интерфейса VPN на проводе не появляется вовсе. Поэтому адрес туннеля ноутбука обычно наименее полезен: он существует только внутри туннеля. Используйте ss или перехват пакетов, чтобы подтвердить источник, который предъявляет клиент, а не считывайте его с экрана настроек.

Две команды покрывают большую часть:

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

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

3. Проверьте, совпадает ли соединение данных

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

Передача, записанная с адреса, отличного от адреса входа, — это реальное наблюдение, а не повреждённая запись, и оно обычно кое-что говорит о пути.

4. Попросите оператора об узкой записи

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

Читайте настоящую схему этого сервера, а не предполагайте, что каждый продукт отдельно записывает исходного клиента, узел управления и узел данных, потому что некоторые сводят всю сессию в одну строку. Держите и протокол ясным: SFTP — это протокол на основе SSH, а не FTP на другом порту, а FTPS добавляет TLS к FTP, поэтому идентичность службы в журнале зависит от того, что именно вы развернули.

5. Проверьте, прежде чем приписывать

Адрес выхода может обслуживать многих клиентов, а одну учётную запись можно использовать из нескольких разрешённых источников, поэтому адрес и имя пользователя не указывают на одну и ту же единицу. Журналирование — это политика сервера: VPN меняет источник, который предъявляет соединение, но не стирает имя учётной записи, имя файла или операцию, которую обработала принимающая служба. Приписывайте только то, что показывает запись, а остальное помечайте как неизвестное. Описание FTP в WinSCP — компактная справка по модели с двумя соединениями, если нужно объяснить её кому-то ещё.

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