Как проверить доступность порта udp

Проверка открытых портов с помощью PowerShell

05.07.2023

itpro

PowerShell, Windows 10, Windows 11, Windows Server 2019

комментариев 7

В PowerShell для проверки доступности порта на удаленном компьютере можно использовать командлет Test-NetConnection. Этот командлет позволяет проверить доступность удаленного сервера или службы на нем, протестировать блокируется ли TCP порт файерволами, проверить доступность по ICMP и маршрутизацию. По сути, командлет Test-NetConnection позволяет заменить сразу несколько привычных сетевых утилит: ping, traceroute, telnet, сканер TCP портов и т.д.

Проверка доступности TCP порта с помощью Test-NetConnection

Командлет Test-NetConnection можно использовать только для проверки TCP портов. Например, чтобы проверить, что на почтовом сервере открыт порт TCP 25 (SMTP протокол), выполните команду:

Test-NetConnection -ComputerName msk-msg01 -Port 25

Примечание. С помощью командлета Test-NetConnection можно проверить только TCP соединение, для проверки доступности UDP портов он не применим.

В сокращенном виде аналогичная команда выглядит так:

TNC msk-mail1 -Port 25

Разберем результат команды:

ComputerName : msk-msg01 RemoteAddress : 10.10.1.7 RemotePort : 25 InterfaceAlias : CORP SourceAddress : 10.10.1.70 PingSucceeded : True PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : True

Как вы видите, командлет выполняет разрешение имени сервера в IP адрес, выполняется проверка ответа ICMP (аналог ping) и проверка ответа от TCP порта (доступность). Указанный сервер доступен по ICMP ( PingSucceeded = True ) и 25 TCP порт также отвечает ( RemotePort=25, TcpTestSucceeded= True ).

Примечание. Если команда вернула PingSucceeded=False и TcpTestSucceeded= True, скорее всего означает, что на удаленном сервере запрещен ICMP Ping.

Если выполнить команду Test-NetConnection без параметров, выполнится проверка наличия подключения к интернету на компьютере (проверяется доступность узла internetbeacon.msedge.net):

Для вывода детальной информации при проверки удаленного TCP порта можно добавить опцию -InformationLevel Detailed:

TNC 192.168.31.102 -Port 3389 -InformationLevel Detailed

Доступность популярных сервисов Windows на удаленном компьютере (HTTP, RDP, SMB, WINRM) можно проверить с помощью параметра CommonTCPPort.

Например, чтобы проверить доступность веб-сервера, можно использовать команду:

Test-NetConnection -ComputerName winitpro.ru -CommonTCPPort HTTP

Test-NetConnection msk-rds1 –CommonTCPPort RDP

Можно вывести все параметры, которые возвращает командлет Test-NetConnection:

Test-NetConnection msk-man01 -port 445|Format-List *

Если нужна только информация по доступности TCP порта, в более лаконичном виде проверка может быть выполнена так:

TNC msk-mail1 -Port 25 -InformationLevel Quiet

Командлет вернул True, значит удаленный порт доступен.

Совет. В предыдущих версиях Windows PowerShell (до версии 4.0) проверить доступность удаленного TCP порта можно было так:

(New-Object System.Net.Sockets.TcpClient).Connect(‘msk-msg01’, 25)

Командлет Test-NetConnection можно использовать для трассировки маршрута до удаленного сервера при помощи параметра –TraceRoute (аналог команды трассировки маршрута tracert). С помощью параметра –Hops можно ограничить максимальное количество хопов при проверке.

Test-NetConnection msk-man01 –TraceRoute

Командлет вернул сетевую задержку при доступе к серверу в миллисекундах ( PingReplyDetails (RTT) : 41 ms ) и все IP адреса маршрутизаторов на пути до целевого сервера.

PowerShell: проверка открытых портов на нескольких IP хостах

С помощью PowerShell можно проверить доступность определенного порта на нескольких компьютерах. Сохраните список серверов или IP адресов в текстовый файл servers.txt.

Например, ваша задача – найти сервере на которых не отвечает или закрыт порт TCP/25:

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

Например, вы можете проверить доступность основных служб на всех контроллерах домена в AD (список DC можно получить командлетом Get-ADDomainController). Проверим следующие службы на DC (в утилите PortQry есть аналогичное правило Domain and trusts):

• RPC – TCP/135
• LDAP – TCP/389
• LDAP – TCP/3268

$Ports = «135»,»389″,»636″,»3268″,»53″,»88″,»445″,»3269″, «80», «443»
$AllDCs = Get-ADDomainController -Filter * | Select-Object Hostname,Ipv4address
ForEach($DC in $AllDCs)Foreach ($P in $Ports)$check=Test-NetConnection $DC.Ipv4address -Port $P -WarningAction SilentlyContinue
If ($check.tcpTestSucceeded -eq $true)
«>
else
» -ForegroundColor Red>
>
>

Скрипт проверит указанные TCP порты на контроллерах домена, и, если один из портов недоступен, выделит его красным цветом (можно запустить данный PowerShell скрипт как службу Windows).

IP сканер сети на PowerShell

Вы можете реализовать простой IP сканер, которые сканирует удаленные хосты или IP подсети на открытые/закрытые TCP порты.

Чтобы просканировать диапазон IP адресов с 10.10.10.5 до 10.10.10.30 и вывести компьютеры, на которых открыт порт 3389:

foreach ($ip in 5..30)

Можно просканировать диапазон TCP портов (от 1 до 1024) на указанном сервере:

Вывести список открытых портов в Windows

Если вам нужно вывести список портов, открытых на локальном компьютере, исопльзуется командлет Get-NetTCPConnection (это PowerShell-эквивалент NETSTAT). Полный список открытых портов на компьютере можно вывести так:

Get-NetTcpConnection -State Listen | Select-Object LocalAddress,LocalPort| Sort-Object -Property LocalPort | Format-Table

Командлет Get-NetTCPConnection также можно использовать для просмотра списка открытых TCP/IP подключений.

Если вам нужно проверить, какая программа (процесс) слушает определенный порт на вашем компьютере, выполните команду:

Get-Process -Id (Get-NetTCPConnection -LocalPort 443).OwningProcess | ft Id, ProcessName, UserName, Path

Предыдущая статья Следующая статья

Testing UDP Port Connectivity

In Linux, there are useful tools using which we can test whether a UDP port is open for connection or not. In this tutorial, we’re going to see how we can use some of those tools to test UDP port connectivity.

An effective way to achieve this is port checking or port scanning. The port scanning technique determines which ports on the system are open and possibly receiving or transmitting data. We can scan the status of a port on the targeted system using one of these tools.

2. Using nmap

Network Mapper (shortened to nmap) is a network exploration tool. Depending on the options, nmap outputs a list of scanned targets with some additional information. In fact, we can use nmap to check the state of a UDP port by running nmap via the target’s IP address:

$ nmap -sU -v 172.16.38.137 Starting Nmap 6.47 ( http://nmap.org ) at 2022-07-22 22:21 IST Initiating Parallel DNS resolution of 1 host. at 22:21 Completed Parallel DNS resolution of 1 host. at 22:21, 0.01s elapsed Initiating UDP Scan at 22:21 Scanning 172.16.38.137 [1000 ports] . UDP Scan Timing: About 68.43% done; ETC: 22:23 (0:00:54 remaining) Completed UDP Scan at 22:24, 189.80s elapsed (1000 total ports) Nmap scan report for 172.16.38.137 Host is up (0.00011s latency). Not shown: 997 closed ports PORT STATE SERVICE 123/udp open ntp 631/udp open|filtered ipp 5353/udp open|filtered zeroconf Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 190.12 seconds Raw packets sent: 1075 (30.959KB) | Rcvd: 2145 (91.614KB) 

Here, the -sU option specifies a UDP scan. Additionally, we added the -v option for verbosity. From the scan’s output, we notice that UDP ports 123, 631, and 5353 are open. Furthermore, two of them are also filtered.

UDP port scan using nmap works by sending UDP packets of mostly no payload to each port on the targeted system. As an output, a table lists the port number with protocol, state of the port, and the service name.

The ports can have different states:

• open – an application on the target machine is listening for a connection on this port
• closed – no application is listening on this port
• filtered – port responds as if behind a firewall or other network obstacle
• unfiltered – port is responsive, but nmap is unable to classify it

Moreover, sometimes the output is a combination of two states like open|filtered or closed|filtered. This happens when nmap is unable to determine which of those two states the port has.

3. Using netcat

The netcat or nc command is a very useful networking utility in Linux. It allows us to read from and write to TCP or UDP connections. Some of the popular features of netcat are inbound or outbound TCP or UDP connections, port-scanning, data transfer, netcat relay, etc.

To check UDP connectivity, we can use netcat with the targeted IP and port:

$ nc -vz -u 8.8.8.8 443 Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connected to 8.8.8.8:443. Ncat: UDP packet sent successfully Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.

Here, we see the UDP packet was sent successfully, so we expect UDP port 443 to be open on 8.8.8.8.

The default protocol is TCP, so we specify UDP via the -u option. The -z option specifies a port scan. Combined with -u, -z sends empty UDP packets by default. If we want to send UDP payloads from a file, we can do that by appending -N with a filename as its argument. Finally, -v is used for more verbose output.

4. Using iperf

iperf is a network throughput measurement tool that can test the throughput of either UDP or TCP. We can also use this tool to validate UDP connectivity. iperf works in a client-server setup. So, we need to establish both a client and a server to use it.

Firstly, we initiate iperf on the server side using the -s (server) option:

$ iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------

Then, we need to start this tool on the client side, targeting the server’s IP. We use -u to specify UDP, while the -c option indicates that this is the client:

$ iperf3 -u -c 172.16.38.137 Connecting to host 172.16.38.137, port 5201 [ 4] local 172.16.38.136 port 38369 connected to 172.16.38.137 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 120 KBytes 983 Kbits/sec 15 [ 4] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 16 [ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 16 [ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 16 [ 4] 4.00-4.52 sec 80.0 KBytes 1.26 Mbits/sec 10 . 

From the above output, we can see that client is connected to the server on port 5201.

5. Conclusion

In this article, we explored three command-line tools: nmap, netcat, and iperf. Using these, we can check the connectivity status of UDP ports.

PortQry — утилита для проверки доступности TCP/UDP портов из Windows

08.07.2020

itpro

Windows 10, Windows Server 2012 R2, Windows Server 2016, Утилиты

Комментариев пока нет

Несмотря на то, что в Windows есть множество инструментов для диагностики проблем в TCP/IP сетях (ping, telnet, pathping и т.д.), не все они позволяют в удобном виде проверить состояние или выполнить сканирование открытых сетевых портов на удаленном сервере. Утилита Portqry.exe является удобным инструментом проверки доступности TCP/UDP портов на удаленном сервере при диагностике проблем, связанных с функционированием различных сервисов, а также наличием файерволов и межсетевых экранов в TCP/IP сетях. Чаще всего утилита Portqry используется как более функциональная замена telnet, и в отличии от telnet, позволяет также проверять открытые UDP порты.

Используем PortQry для сканирования открытых UDP и TCP портов

Первая версия Portqry для Windows Server 2003 некорректно работает с более новыми ОС (Windows Server 2008 и выше), поэтому в дальнейшем была выпущена вторая версия утилиты PortQryV2. Именно эту версию и стоит использовать сегодня(скачать утилиту PortQryV2 можно по ссылке).

В Windows 10 вы можете установить portqry через менеджер пакетов Chokolatey:

choco install portqry

Скачайте и распакуйте архив PortQryV2.exe. Запустите командную строку и перейдите в каталог с утилитой, например:

Чтобы проверить доступность DNS сервера с клиента, необходимо проверить открыты ли на нем 53 порты TCP и UDP. Формат команды проверки доступности портов на удаленном сервере следующий:

PortQry -n server [-p protocol] [-e || -r || -o endpoint(s)]

-n – имя или IP адрес сервера, доступ к которому нужно проверить
—e – номер порта для проверки (от 1 до 65535)
—r – диапазон портов для проверки (например, 1:80)

—p – по какому протоколу выполняется проверка. Это может быть TCP, UDP или BOTH (по умолчанию используется TCP).

Примечание. В отличии от комадлета PowerShell Test-NetConnection, который может использоваться только для проверки доступности TCP портов, утилита PortQry поддерживает и TCP и UDP протоколы.

В нашем примере команда будет такой:

PortQry.exe –n 10.1.10.6 -p both -e 53

Утилита Portqry для каждого указанного порта вернет один из трех статусов доступности:

• Listening – означает, что указанный порт доступен (принимает соединения), ответ от него получен;
• NotListening – на целевой системе не запушен процесс (служба), который бы принимал подключения на указанном порту. Portqry получила ответ ICMP «Destination Unreachable — Port Unreachable» при проверке UDP порта, или TCP пакет с флагом Reset;
• Filtered – утилита PortQry не получала ответа от указанного порта либо ответ был отфильтрован. Т.е. на целевой системе либо не слушается данный порт, либо доступ к нему ограничен файерволом или настройками системы. По умолчанию TCP порты опрашиваются 3 раза, а UDP – один.

В нашем примере, DNS сервер доступен с клиента и по TCP и по UDP.

TCP port 53 (domain service): LISTENING UDP port 53 (domain service): LISTENING

С помощью атрибута —o, можно указать последовательность портов, которых нужно просканировать:

portqry -n 10.1.10.6 -p tcp -o 21,110,143

Следующая команда выполнит сканирование диапазона “низких” TCP портов и вернет список доступных портов, которые принимают подключения (утилита работает в режиме сканера открытых портов):

portqry -n 10.1.10.6 -r 1:1024 | find «: LISTENING»

Можно сохранить результаты сканирования открытых портов в текстовый файл:

portqry -n 10.1.10.6 -p tcp -r 20:500 -l logfile.txt

В утилите portqry есть интерактивный режим:

Теперь в приглашении PortQry Interactive Mode можете указать имя удаленного компьютера и порт.

node srv-lic
set port=80

Чтобы выполнить проверить порт на указанном сервере нажмите q и Enter.

С помощью аргументов –wport и -wpid можно выполнить мониторинг состояния указанного порта (wport), или всех портов, связанных с указанным процессом (wpid) на локальном хосте.

Например, следующая команда в течении 10 минут будет выполнять проверку доступности указанного локального порта (например, RDP порта 3389), и если его статус изменится, уведомит администратора об этом (подробный лог будет доступен в файле LogFile.txt). Чтобы остановить мониторинг, нажмите Ctrl-C :

portqry -wport 3389 -wt 600 –l LogFile.txt -y -v

Можно получить информацию об открытых портах и активных TCP/UDP соединениях на локальном компьютере:

Расширенный статус сетевых служб в PortQry

В утилите PortQry имеется встроенная поддержка некоторых сетевых служб. Это LDAP, Remote Procedure Calls (RPC), почтовые протоколы (SMTP, POP3 и IMAP4), SNMP, FTP/ TFTP, NetBIOS Name Service, L2TP и другие. Кроме проверки доступности этих стандартных портов этих служб, утилита выполняет специфические для конкретного протокола запросы для получения статуса сервиса.

Например, с помощью следующего запроса мы не только проверим доступность службы RPC endpoint mapper (TCP/135), но и получим список имен зарегистрированных в системе конечных точек RPC (в том числе их имя, UUID, адрес к которому они привязаны и приложение, с которым они связаны).

portqry -n 10.1.10.6 -p tcp -e 135

TCP port 135 (epmap service): LISTENING Using ephemeral source port Querying Endpoint Mapper Database. Server's response: UUID: d95afe72-a6d5-4259-822e-2c84da1ddb0d ncacn_ip_tcp:10.1.10.6 [49152] UUID: 897e215f-93f3-4376-9c9c-fd2277495c27 Frs2 Service ncacn_ip_tcp:10.1.10.6 [5722] UUID: 6b5bd21e-528c-422c-af8c-a4079be4fe48 Remote Fw APIs ncacn_ip_tcp:10.1.10.6 [63006] UUID: 12345678-1234-abcd-ef22-0123456789ab IPSec Policy agent endpoint ncacn_ip_tcp:10.1.10.6 [63006] UUID: 367abb81-9844-35f1-ad32-91f038001003 ncacn_ip_tcp:10.1.10.6 [63002] UUID: 50abc2a3-574d-40b3-1d66-ee4fd5fba076 ncacn_ip_tcp:10.1.10.6 [56020] …….. UUID: 3c4428c5-f0ab-448b-bda1-6ce01eb0a6d5 DHCP Client LRPC Endpoint ncacn_ip_tcp:10.1.10.6 [49153] Total endpoints found: 61 ==== End of RPC Endpoint Mapper query response ==== portqry.exe -n 10.1.10.6 -e 135 -p TCP exits with return code 0x00000000.

Или вы можете проверить доступность и ответ от службы SQL Server Browser на сервере Microsoft SQL Server:

PortQry.exe -n msk-sql1 -e 1434 -p UDP

UDP port 1434 (ms-sql-m service): LISTENING or FILTERED Sending SQL Server query to UDP port 1434. Server's response: ServerName MSK-SQL01 InstanceName MSSQLSERVER IsClustered No Version 15.0.2000.5 tcp 53200 ServerName MSK-SQL01 InstanceName BANKDB IsClustered No Version 15.0.2000.5 tcp 1433 ==== End of SQL Server query response ==== UDP port 1434 is LISTENING

Как вы видите, утилита portqry показала не только доступность UDP порта, но и версию SQL сервера и имена запущенных на сервере SQL экземпляров и их TCP порты (один инстанс BANKDB живет на порту по умолчанию tcp 1433, второй MSSQLSERVER использует фиксированный порт из RPC диапазона 53200 — см. статью о настройке портов в SQL Server).

Можно опросить SNMP порт на устройстве, указав название community:
portqry -n host2 -cn !secure! -e 161 -p udp

При проверке 25 порта на SMTP сервере можно получить баннер приветствия сервера:

portqry -n domain.mail.ru -p tcp -e 25

Графический интерфейс для Portqry

Первоначально утилита Portqry была исключительно консольным инструментом. Для удобства пользователей, которые не дружат с командной строкой, Microsoft разработала простой графический интерфейс для утилиты portqry – PortQueryUI. Скачать PortQueryUI можно с сайта загрузок Microsoft http://download.microsoft.com/download/3/f/4/3f4c6a54-65f0-4164-bdec-a3411ba24d3a/PortQryUI.exe

PortQueryUI по сути представляет собой графическую надстройку над portqry для формирования командной строки, и возврата результата в графическое окно.

Кроме того, в PortQueryUI заложено несколько заранее предопределенных наборов запросов для проверки доступности популярных служб Microsoft:

• Domain and trusts (проверка служб на контроллере домена Active Directory)
• IP Sec
• Networking
• SQL Server
• Web Server
• Exchange Server
• Net Meeting

Думаю, особых комментариев к интерфейсу PortQueryUI давать не нужно. Все должно быть понятно из скриншота ниже. Укажите DNS имя или IP адрес сервера, выберите один из предустановленных сервисов (Query predefined service), или укажите номера портов для проверки вручную (Manually input query ports) и нажмите кнопку Query.

Возможные коды ответа в PortQueryUI (выделен на скриншоте):

• 0 (0x00000000)– означает, что соединении успешно установлено и порт доступен;
• 1 (0x00000001) – указанный порт недоступен или отфильтрован;
• 2 (0x00000002 – это нормальный код возврата при проверке UDP подключения, т.к. не возвращается ACK ответ.

Предыдущая статья Следующая статья

Testing UDP port connectivity

I am trying to test whether I can get to a particular port on a remote server (both of which I have access to) through UDP. Both servers are internet facing. I am using netcat to have a certain port listening. I then use nmap to check for that port to see if it is open, but it doesn’t appear to be. Iptables is turned off. Any suggestions why this could be? I am eventually going to setup a VPN tunnel, but because I’m very new to tunnels, I want to make sure I have connectivity on port UDP 1194 before advancing.

103 5 5 bronze badges
asked Aug 10, 2012 at 8:42
1,657 7 7 gold badges 26 26 silver badges 33 33 bronze badges

I’ve respondend to the «Testing UDP port connectivity» question. But I suggest to concentrate on the more specific «make sure OpenVPN receives my UDP packets» part — that could be easily achieved by looking at OpenVPN logs.

Aug 10, 2012 at 12:16

10 Answers 10

There is no such thing as an «open» UDP port, at least not in the sense most people are used to think (which is answering something like «OK, I’ve accepted your connection»). UDP is session-less, so «a port» (read: the UDP protocol in the operating system IP stack) will never respond «success» on its own.

UDP ports only have two states: listening or not. That usually translates to «having a socket open on it by a process» or «not having any socket open». The latter case should be easy to detect since the system should respond with an ICMP Destination Unreachable packet with code=3 (Port unreachable). Unfortunately many firewalls could drop those packets so if you don’t get anything back you don’t know for sure if the port is in this state or not. And let’s not forget that ICMP is session-less too and doesn’t do retransmissions: the Port Unreachable packet could very well be lost somewhere on the net.

A UDP port in the «listening» state may not respond at all (the process listening on it just receives the packet and doesn’t transmit anything) or it could send something back (if the process does act upon reception and if it acts by responding via UDP to the original sender IP:port). So again, you never know for sure what’s the state if you don’t get anything back.

You say you can have control of the receiving host: that makes you able to construct your own protocol to check UDP port reachability: just put a process on the receiving host that’ll listen on the given UDP port and respond back (or send you an email, or just freak out and unlink() everything on the host file system. anything that’ll trigger your attention will do).