Проверка доступности сетевых служб в случае, когда обычный пинг закрыт #37
В целях повышения безопасности виртуализованных сетей производителем закрыто использование протокола icmp, таким образом диагностика виртуализованной сети не возможна с помощью привычной утилиты ping.
Однако, доступен протокол tcp, и для диагностики сетевой доступности сервиса, размещенного в SDN/ SDN 2.0 сети, рекомендуется использовать утилиту tcping.exe.
2) разместить файл tcping.exe в конкретной папке на диске C (например, в корне)
Способы проверки доступности TCP-портов
В процессе разворачивания и эксплуатации информационных систем часто требуется проверка доступности порта того или иного ресурса. Это может быть сервер приложений 1С, к которому не удается подключиться пользователю. Или же это внешний веб-ресурс, к которому происходит обращение. Или что-то еще.
Для проверки доступности самого сервера обычно используется команда ping. Но, в силу того, что данная утилита работает с ICMP-пакетами, для конкретного порта проверить доступ таким образом невозможно. Кроме того, на ресурсе в целях безопасности может быть заблокирован ответ на ICMP-пакеты, соответственно, результат доступности нельзя считать однозначным, если ресурс «не пингуется».
Как проверить доступен ли порт?
Традиционный способ.
Первое, что приходит на ум — использовать «старый добрый» telnet.
Для примера проверять будем доступность менеджера кластера:
C:>telnet ks-app-02 2141
Получили в ответ «кракозябру» — значит доступ есть
Осталось выйти сначала из кракозябры по ‘CTRL+]’ и затем из самого telnet-а
Microsoft Telnet> q
Загвоздка в том, что в большинстве современных Windows-систем telnet-клиент не установлен по-умолчанию, и требуется доустанавливать этот компонент. Что не всегда возможно, т.к. компьютер может быть и не своим и/или нет соответствующих прав.
Способ без инсталляции программ.
Хотелось бы иметь какой-то инструмент, не требующий установки, портабельный, чтобы можно было его просто скопировать и пользоваться, а при необходимости, легко удалить после использования.
В качестве такого инструмента удобно использовать утилиту psping от Sysinternals.
Эту утилиту можно скачать как отдельно, так и в составе пакета SysinternalsSuite, который содержит множество других необходимых инструментов.
C:>psping ks-app-02:2141
Еще один портабельный инструмент, позволяющий решить задачу:
tcping (
Встроенный инструментарий.
Однако есть возможность обойтись и совсем без сторонних утилит. В Windows есть встроенный инструмент, позволяющий выполнить такую проверку.
Это powershell-командлет Test-NetConnection
PS C:> Test-NetConnection ks-app-02 -Port 2141
В ответе нас интересует последняя строка — TcpTestSucceeded: True. В данном случае — доступ есть.
Также, в ответе может содержаться еще значение PingSucceeded — это «обычный» ping по ICMP.
У командлета есть очень удобный для запоминания и быстрого ввода альяс tnc, а также ключ позволяющий ограничить вывод только результатом.
C:>tnc ks-app-02 -Port 2141 -InformationLevel Quiet
Разумеется, запускать командлет необходимо в окне PowerShell, а не «командной строки».
Хотя, из командной строки тоже можно, вызвав PowerShell:
C:>powershell tnc ks-app-02 -port 2141
Следует заметить, что командлет доступен в версиях PowerShell от 4.0 и выше, т.е. начиная с Windows Server 2012 R2 и Windows 8.1
Как поймать вредителя или почему ломается curl?
Есть сервер. На сервере сборка (винда, студия и всё такое). В процессе сборки запускается нинзя, который запускает питон, который запускает curl, который отправляет файлик на другой сервер.
Раз в неделю эта замечательная конструкция встаёт раком и curl начинает стабильно возвращать код 55: типа «не могу отправить файл на [другой] сервер».
Если пойти по RDP и позвать curl из консольки, то всё работает.
Эффект воcпроизводится стабильно и лечится. перезагрузкой сервера. Или EMET-а. Или касперского.
Хотя в логах у последнего всё чисто.
Визуально, curl успевает отправить несколько МБ на [другой] сервер, после чего залипает минут на 5.
Видимо, после этого у [другого] сервера срабатывает таймаут, и curl честно пишет «ну не шмогла я».
Есть идеи, что может помешать curl-у дочитать файл с диска?
Точно воспроизвести что-то типа «отключил каспера, всё заработало» не получается 🙁
Как это вообще диагностировать?
- Вопрос задан более трёх лет назад
- 425 просмотров
4 комментария
Оценить 4 комментария
Точно воспроизвести что-то типа «отключил каспера, всё заработало» не получается 🙁
Почему не удается?
Как на счет того, чтобы отключить его полностью, перезагрузить машину (чтобы гад даже не поднимался во время загрузки) и протестировать скрипт.
Вова @JustMoose Автор вопроса
nirvimel: Потому что он может нормально работать неделями с включенным каспером и еметом. И ломается неожиданно. Нет очевидной причины вида «включил — сломалось». Есть только «наблюдения» вида «выключил — заработало».
Вова: Другими словами: при включении Каспера появляется вероятность возникновения проблемы.
Думаю, в эту сторону стоит копать.
Вова @JustMoose Автор вопроса
nirvimel: Ага. Только доказать я этого не могу 🙂
И отключить на месяц каспера, чтобы понять, что всё ок, тоже не могу.
Решения вопроса 0
Ответы на вопрос 1
younghacker @younghacker
Я бы собирал диагностику сети.
Перед curl или после того как он вернул ошибку запускаете несколько программ которые записывают информацию в лог.
1) пинг себя, гейтвея, гуглднс и целевого хоста по IP. (в зависимости от сетей размещения источника и цели)
2) трейсроут до целевого хоста без лукапа имён
3) переменные окружения (кто я) списки процессов и так далее.
4) телнет (tcping) в порт целевого хоста и постороннего хоста для сравнения. Чтобы проверить не блокирует ли вас антивирус или целевой хост.
5) помотреть логи целевого сервера. Увеличить информативность логов.
6) воткнуть хост в роутер (linuxbox) на нём собрать трафик по интересующему порту (tcpdump в файл)
7) поставить на хосте виновнике https://www.winpcap.org/ и писать трафик в файл затем посмотреть в wireshark что происходит.
8) утилиты Марка Русиновича sysinternals для анализа что там происходит с сеткой, процессы, соединения порты, ошибки работы с файлами реестром и так далее.
9) попробовать отправить файл при помощи PowerShell или любой другой утилиты вместо пайтона и curl
Стабильность возврата ошибки по идее даёт возможность найти виновника. Но «войти по RDP» имеет много отличий от запуска от имени системы или таймера. Поэтому у Вас по RDP это работает.
Ответ написан более трёх лет назад
Вова @JustMoose Автор вопроса
Прочитал твой ответ, прифигел, и забыл о нём на месяц.
Постфактум могу сказать следующее: проблема не в том, чтобы собрать данные, а в том, чтобы их проанализировать. Я умею пользоваться пингом и прокмоном, и даже немножко фиддлером. Но легче от этого не становится. Ибо не понятно, что и как в полученных гигабайтах потом искать. По хорошему, даже если точно знать, что в данной проблеме виноват каспер и именно он зависает, то процесс поиска «вот тут у него случился дедлок» несколько нетривиален.
younghacker @younghacker
А как иначе?
Но собирать данные нужно в тот момент когда что-то там ломается curl начинает возвращать код 55. Нужно добиться повторения ошибки и анализировать что перестало работать.
Проверка открытых портов с помощью 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
Предыдущая статья Следующая статья 