Почему скан портов меняется при запуске через sudo

Nmap не всегда отправляет тот пакет, который вы, как вам кажется, запросили. Когда сырые сокеты недоступны, он заменяет стандартное SYN-сканирование на TCP connect-сканирование, поэтому запуск от обычного пользователя и запуск под sudo могут отвечать на разные вопросы об одном и том же порту. Результаты выглядят как проблема прав, а обычно это смена метода. Явное указание метода — единственный способ вообще сравнить два запуска.

Два зонда, один порт, разные пути в коде

SYN-сканирование само собирает заголовок TCP, отправляет его из сырого сокета и читает ответ из сети ещё до того, как стек TCP ядра вообще зафиксирует завершённое соединение. Connect-сканирование просит операционную систему открыть обычный сокет и сообщает то, что возвращает connect(). Оба могут назвать порт открытым, но только одно оставляет полуоткрытую попытку и только одно подчиняется политике уровня сокета, привязанной к отправляющему процессу.

Сырому пути нужен CAP_NET_RAW, поэтому стандартное сканирование тихо деградирует, когда этой возможности нет. Собственный справочник по техникам сканирования Nmap документирует замену: connect-сканирование — это запасной вариант, потому что оно вообще не требует особых прав. Подмена происходит без предупреждения в большинстве запусков, и именно поэтому её так легко прочитать неверно. Как только вы знаете, что запасной вариант существует, «открыто под root, закрыто под пользователем» перестаёт звучать как ошибка прав и начинает звучать как два разных измерения.

Что sudo на самом деле меняет в сканировании

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

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

Держите метод неизменным в обоих запусках

Заставьте оба вызова использовать одну и ту же технику, и сравнение начнёт что-то значить. Флаг -sT явно запрашивает connect-сканирование, -Pn убирает обнаружение хостов, -n убирает разрешение имён, а один -p убирает различия в списке портов.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

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

Контекст учётной записи — не только флаг прав

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

Изучайте политику, а не право. В Linux nftables выражает это через meta skuid, а iptables — через совпадение владельца, и любое из них может отправить один UID в туннель, пока другое продолжает использовать физический маршрут по умолчанию.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

Подтвердите зонд, прежде чем сравнивать результаты

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

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

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