Тестирование подключения к UDP-порту

Чтобы проверить, отвечает ли порт udp, используйте netcat.

Пример из страница руководства:

nc -v -u -z -w 3 example.host 20-30
    Send UDP packets to ports 20-30 of example.host, and report which ones
    did not respond with an ICMP packet after three seconds.

Конечно, если брандмауэр DROPing, что обычно имеет место при работе со шлюзами, подключенными к Интернету, вы не получите ответа ICMP.

Не существует такой вещи, как «открытый» UDP-порт, по крайней мере, в том смысле, в котором большинство людей привыкло думать (который отвечает что-то вроде «ОК, я принял ваше соединение»). UDP не поддерживает сеанс, поэтому «порт» (читай: протокол UDP в IP-стеке операционной системы) никогда не ответит «успешно» сам по себе.

Порты UDP имеют только два состояния: прослушивание или нет. Обычно это означает «открытие сокета процессом» или «отсутствие открытого сокета». Последний случай должен быть легко обнаружен, поскольку система должна ответить Пункт назначения ICMP недоступен пакет с кодом = 3 (порт недоступен). К сожалению, многие брандмауэры могут отбрасывать эти пакеты, поэтому, если вы ничего не получите обратно, вы точно не знаете, находится порт в этом состоянии или нет. И давайте не будем забывать, что ICMP тоже не требует сеанса и не выполняет повторных передач: пакет Port Unreachable вполне может быть потерян где-то в сети.

Порт UDP в состоянии "прослушивания" может вообще не отвечать (прослушивающий его процесс просто получает пакет и ничего не передает) или может отправить что-то обратно (если процесс действительно действует при приеме). и если он действует, отвечая через UDP на исходный IP-адрес отправителя: порт). Итак, опять же, вы никогда не узнаете наверняка, в каком состоянии, если ничего не получите обратно.

Вы говорите, что можете контролировать принимающий хост: это позволяет вам создать свой собственный протокол для проверки доступности порта UDP: просто поместите процесс на принимающий хост, который будет прослушивать данный порт UDP. и ответить (или отправить вам электронное письмо, или просто сходить с ума и unlink() все в файловой системе хоста ... все, что привлечет ваше внимание, подойдет).

1. как на клиентском сервере, так и на сервере установите nc: yum install nc (для centos)
2. на сервере прослушивает UDP-порт: nc -ul 6111
3. на клиенте nc -u <server> 6111
4. введите что-нибудь на клиенте и нажмите Enter - вы должны увидеть этот текст на сервере

Примечание: Когда вы запускаете nc -ul команду на сервере, она будет только connect для первого приходящего к нему подключения. Вы не можете, как я выяснил, переключаться между серверами, пингуя его, без остановки и перезапуска nc -ul. Фактически, если вы ^ C остановите клиента (nc -u ...), вы также не можете перезапустить клиент, не перезапустив предварительно прослушиватель сервера.

У меня была аналогичная проблема, и я нашел хорошее решение, используя netcat здесь: http://en.wikipedia.org/wiki/Netcat#Test_if_UDP_port_is_open:_simple_UDP_server_and_client

nc -vzu <host> <port>

Я смог подтвердить, что мой UDP-порт открыт, а затем смог приступить к тестированию своего реального кода.

Тестирование открытых UDP-портов с помощью nmap чревато опасностями - нет трехстороннего рукопожатия, указывающего на открытость. Если процесс прослушивания не отвечает на все, что отправляет Nmap, Nmap не сможет отличить открытый порт, который не отвечает, и порт с фильтром.

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

Вы можете сканировать порты udp, используя следующую команду

nmap -sU -v <hostname or ip>

Вы можете сделать это с помощью netcat (NC) или iperf, предполагая, что у вас есть другая машина для тестирования вне сети. Мой выбор был бы nmap Сканирование UDP из системы за пределами вашей среды. Какая у вас была командная строка nmap? Есть ли какие-нибудь аппаратные брандмауэры или другие устройства?

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

LINE: while(1)
{
    my $line;
    my $flags;

    local $SIG{ALRM} = sub {die "exceeded timeout for recv"};
    alarm 5;
    eval {
        $socket->recv($line,2024,$flags);
    };

    unless($line =~ /\{.*\}/){
        if($verbose){
            print STDERR "Invalid or empty dgram:\n",'"', $line, '"',"\n";
        }

        last LINE;
    }
}

Фактически, если сервер прослушивает порт 6111, netcat явно указывает это:

# nc -ul 6111
Ncat: bind to :::6111: Address already in use. QUITTING.