2012-06-04 16 views
4

Как проверить, открыт ли удаленный UDP-порт с помощью родного C++? Поскольку UDP не поддерживает соединение, вызов connect() не помогает. Я не могу попробовать привязать его, поскольку он не является локальным. nmap также не может указывать. (однако netstat может узнать, но я думаю, что он смотрит внутреннюю информацию об открытых портах/файлах). Есть ли способ обнаружить это? Если я выйду на уровень ниже уровня сети, можно ли отправить ICMP-сообщение на C++, чтобы проверить статус недоступного порта? Я имею в виду, что это даст достаточно информации о статусе порта?Проверка открытого порта UDP на C++

Платформа - это Linux.

+0

«Родной язык C++» на какой ОС/платформе? – 0xC0000022L

+0

Это на платформе Linux – Mustafa

+0

Язык не является проблемой здесь, как уровень привилегий, на котором выполняется ваш код. Например, вы могли бы, как и «nmap», использовать библиотеку libpcap из вашего кода на C++. Кроме того, я думаю, что если вы попробуете все опции «nmap», вы получите хотя бы указание о том, что порт, вероятно, открыт или отфильтрован, даже если не со 100% уверенностью во всех случаях. Какие параметры используются с 'netstat' и' nmap', где вы используете? – 0xC0000022L

ответ

4

Я предполагаю, что вы пытаетесь определить, проходит ли UDP-порт на удаленной машине через брандмауэр и/или имеет приложение, запущенное на нем.

Вы не можете достоверно определить это. Ближе всего вы можете попытаться отправить несколько небольших дейтаграмм на этот адрес и порт с интервалом около 1 секунды в течение примерно 10 секунд.

Если брандмауэры не блокируют порт, и приложение не работает, удаленная система может отправить обратно ICMP_UNREACH_PORT (порт недоступен). Если блокирующих брандмауэров и удаленной системы нет, маршрутизатор может отправить обратно ICMP_UNREACH_HOST или ICMP_UNREACH_NET. Если брандмауэр блокирует вас, он может отправить обратно ICMP_UNREACH_FILTER_PROHIB, но большинство брандмауэров ничего не отправляют.

Шансы получить любую из этих задних частей довольно тонкие, потому что большинство брандмауэров блокируют подобную ICMP-обратную связь. Даже если ICMP-сообщение действительно возвращается, linux обычно не позволяет вам видеть его, если вы не используете его как root. Некоторые операционные системы сообщают об ошибках ICMP как отказ следующего sendto() на тот же адрес/порт, поэтому вам нужно повторить сообщение несколько раз. Но некоторые не делают этого, и в этом случае вы должны открыть определенный ICMP-порт и проанализировать любые возвращаемые сообщения.

Даже если вы каким-то образом получите сообщение ICMP, поймите, что они ненадежны. Например, вы можете получить ICMP_UNREACH_PORT, даже если приложение не только прослушивает, но и активно отправляет вам данные. (Это редко, но я видел, как это происходит.)

Если приложение запущено на данном порту, и если вы знаете, что это за приложение, и если вы знаете, как создать сообщение, которое заставит это приложение ответить для вас, а затем сделать это и получить ответ - это лучший признак того, что порт открыт. Но отсутствие ответа ничего не значит: возможно, порт заблокирован, возможно, приложение не работает, или, может быть, это просто не понравилось ваше сообщение.

Итог: нет, не совсем.

0

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

Смежные вопросы