Проверка доступности TCP-порта на Windows при диагностике серверов 1С

Проверка доступности ТСР-порта на Windows нужна администратору 1С, когда пользователь или сервис не подключается к хосту, а обычный ping по ICMP не показывает, слушает ли нужный сервис. В памятке - telnet, портабельные утилиты и Test-NetConnection (tnc). Дальше - где ICMP вводит в заблуждение при кластере 8.3, RAS и веб-публикации, и что взять с учётом прав на установку ПО и версии Windows.

Почему ping не подходит для проверки порта

Ping показывает, доходит ли ICMP до хоста. Открыт ли ТСР-порт 1541 или 443 - ping не скажет. До менеджера кластера, ragent или НТТР-публикации эта проба просто не относится. Сервис может слушать 1541, а ICMP на периметре режут: ping молчит, кластер при этом жив.

ICMP и TCP расходятся на маршрутизаторах и в брандмауэре Windows. Отключили ping наружу - это не про 1541. На балансировщике открыли только 443: до VIP ping может не идти, а публикация при этом работает. «Сеть есть» в голове пользователя часто как раз из ping, а тонкий клиент 1С:Предприятие 8.3 к кластеру не цепляется - endpoint host:port для НТТР-сервиса или OData важнее факта ответа ICMP.

Порт проверяют telnet’ом, PsPing или tcping с флешки, либо Test-NetConnection в PowerShell. На Server 2019 на своей админской машине мне обычно хватает tnc; на locked-down ПК пользователя - PsPing без включения компонентов Windows.

Telnet: открывается ли соединение на порт

Клиент telnet пытается установить ТСР-соединение. Если порт доступен и сервер отвечает, вы увидите пустой экран, приглашение или нечитаемые символы от протокола - для бинарного ragent это нормально.

Пример для агента кластера на узле app-1c-03, порт 1541:

C:>telnet app-1c-03 1541

Менеджер кластера по умолчанию слушает 1540 - та же команда, другой порт: telnet app-1c-03 1540.

Пустой экран или «мусор» в кодировке - для ragent нормальный признак установленного TCP. «Could not open connection» или мгновенный отказ - порт закрыт или фильтруется. Долгое ожидание без текста чаще указывает на фильтрацию или асимметричный маршрут, а не на мгновенный RST; для 1541 успех часто выглядит как пустой экран, на других портах картина может отличаться.

Выйти из сеанса: Ctrl+], затем в приглашении Microsoft Telnet команда quit или q. Без выхода сессия висит и мешает следующим пробам на том же порту.

На современных Windows клиент telnet часто не включён. Нужны права администратора и компонент «Клиент Telnet» в «Включение и отключение компонентов Windows». На рабочей станции пользователя или jумр-хосте с жёсткой политикой включить его не всегда получится.

Если telnet включить нельзя, используйте tnc там, где разрешён PowerShell, или PsPing без установки компонентов.

PsPing и tcping: проверка без установки в систему

Когда нельзя трогать компоненты ОС, удобны портабельные exe: скопировали в папку, запустили, удалили. PsPing из Sysinternals Suite (или отдельным файлом) принимает адрес в формате host:port.

C:>psping app-1c-03:1541

В выводе смотрите, устанавливается ли TCP и нет ли ошибок соединения. У PsPing по умолчанию акцент на задержках; для разовой диагностики «открыт ли порт» хватает одного запуска с адресом host:port - важен факт установления TCP, а не замеры ICMP (латентность ping).

Утилита tcping разделяет хост и порт аргументами:

C:>tcping app-1c-03 1541

Оба варианта не требуют PowerShell 4+ и не меняют образ Windows. PsPing удобно держать в общей папке админов рядом с другими утилитами Sysinternals - для площадок без прав на компоненты Windows на ПК пользователя.

Антивирус иногда ругается на незнакомый exe: положите файл в путь, уже разрешённый политикой, или используйте tnc с сервера, где права шире. Это не повод считать порт закрытым.

Test-NetConnection и tnc: встроенная проверка из PowerShell

На Windows Server 2012 R2, Windows 8.1 и новее в PowerShell 4.0+ есть командлет Test-NetConnection. Он умеет явно проверить ТСР-порт ключом -Port.

PS C:> Test-NetConnection app-1c-03 -Port 1541

Для менеджера кластера - тот же вызов с -Port 1540.

Главное поле в ответе - TcpTestSucceeded. Значение «истина» значит: handshake дошёл, порт с вашей точки зрения доступен. «Ложь» - блокировка, неверный host, сервис не слушает или обрыв по пути.

PingSucceeded в том же выводе относится только к ICMP. Его не стоит смешивать с результатом по TCP, если ping намеренно запрещён на периметре: TcpTestSucceeded может быть True при PingSucceeded False и наоборот.

Короткий алиас tnc и тихий режим для скриптов; без -Port командлет ведёт себя ближе к ping и не закрывает задачу проверки конкретного ТСР-сервиса:

PS C:> tnc app-1c-03 -Port 1541 -InformationLevel Quiet

Quiet возвращает только успех или неудачу без длинного отчёта. Командлет удобно запускать в окне PowerShell. Из cmd - однострочник:

C:>powershell -Command "tnc app-1c-03 -Port 1541 -InformationLevel Quiet"

Если политика запрещает интерактивный PowerShell на клиенте, тот же вызов через -Command часто всё же проходит из бат-файла техподдержки. В отдельных GPO режут и такой запуск - это стоит проверить на своей площадке.

На PowerShell старее 4.0 tnc нет - остаются telnet или портабельные утилиты. На актуальных серверах 1С под Windows Server 2019/2022 это уже редкость; версию смотрят через $PSVersionTable.PSVersion, при Major меньше 4 в «первую помощь» для линии поддержки кладут PsPing.

Какие порты 1С 8.3 проверять и какой host подставлять

Типовые значения по умолчанию для кластера серверов 8.3: менеджер кластера 1540, агент (ragent) 1541, RAS 1545. Диапазон портов рабочих процессов задаётся в консоли администрирования кластера и на каждой площадке свой; сверяйте строку подключения и фактические порты ragent с тем, что показывает консоль (при смене портов в кластере меняется LocalPort, а не имя процесса).

Менеджер 1540 нужен, когда не поднимается консоль кластера или не видны рабочие процессы - на этом порту слушает rmngr. Агент 1541 - первая точка для тонкого и толстого клиента, если в строке подключения или ibases.v8i указан прямой адрес сервера или агента; слушает ragent. RAS 1545 - когда ломается удалённое администрирование через RAS (сервер удалённого администрирования).

Для тонкого клиента с рабочей станции host - ДНС-имя или IP из строки подключения: центральный сервер кластера, прямой IP ragent или VIP балансировщика. Port - 1541 (или тот, что задан для агента/менеджера в вашей схеме), если клиент ходит по строке сервера, а не через браузер. После успеха на 1541 порты rphost из диапазона кластера проверяют, если обрыв на этапе сессии или передачи данных.

Веб-клиент и веб-публикация конфигурации на IIS или встроенном НТТР-сервисе слушают порты сайта - часто 80 или 443, иногда нестандарт. Host и port берите из адресной строки браузера или VIP балансировщика перед путём к базе; для HTTPS имя хоста должно совпадать с тем, что в браузере (NAT и SNI на 443). С админской машины в той же VLAN tnc на этот host:port показывает, виден ли listener с сегмента админов.

Отдельно от пользовательской публикации бывает НТТР-сервис для интеграций: в tnc подставляйте host:port из URL вызова (часто тот же IIS или сервер, другой path).

С самого сервера 1С проверяйте 127.0.0.1 на 1540 и 1541: если локально tnc не проходит, проблема в процессах кластера или инбоунд-правилах брандмауэра Windows на этом хосте, а не в маршруте от клиента. С балансировщика гоняйте tnc на backend-IP из pool, а не на «красивое» имя, которое резолвится в другой узел.

Для менеджера кластера 1540 команда та же, меняется только -Port 1540. Если 1540 доступен с сервера, а 1541 нет, смотрите ragent и inbound для агента, а не перезапуск всего кластера подряд.

Рабочий процесс слушает порт из диапазона кластера; номер виден в свойствах процесса в консоли администрирования. tnc гоняют на тот порт, который занят процессом, а не только на 1541 по привычке.

Откуда гонять tnc и что делать при неудачном TcpTestSucceeded

Сначала зафиксируйте host:port из строки подключения. Затем сравните tnc с ПК пользователя, с сервера 1С и с jумр-хоста в той же сети, что и балансировщик. Один False на клиенте и True на сервере почти всегда сеть или фаервол пользователя; успех на backend и неудача с клиентской сети сужает поиск до межсетевых экранов или неверной публикации наружу.

Так вы повторяете путь пользователя и снимаете спор «у нас всё открыто» без повторяемой команды.

Если TcpTestSucceeded ложь, на сервере 1С под Windows проверьте listener, inbound и совпадение имени хоста:

PS C:> Get-NetTCPConnection -LocalPort 1541 -State Listen

Пустой результат при работающем кластере - процесс не поднял порт или слушает другой интерфейс. Альтернатива: netstat -ano и findstr по номеру порта (например 1541), затем сопоставьте PID: при стандартных портах для 1541 - ragent.exe, для 1540 - rmngr.exe; если порты менялись - смотрите LocalPort в консоли кластера.

Второй шаг - правило inbound в брандмауэре Windows для нужного порта (1540, 1541, порт рабочего процесса, RAS). Третий - совпадение имени: строка подключения ссылается на один host, а кластер зарегистрирован на другом DNS; tnc на имя из ibases.v8i и на IP из консоли кластера часто расходятся.

Новички нередко проверяют порт на одном узле кластера, а пользователь подключён к другому через балансировщик. Уточните, какой backend смотрите, прежде чем перезапускать ragent не на том сервере.

Для НТТРС-публикации успешный TCP на 443 ещё не гарантирует доверие к сертификату. После удачного tnc на Windows 10 и Server 2016+ TLS проверяют отдельно встроенным curl.exe - path берут из публикации, ключ -k только для диагностики, не как норма эксплуатации:

C:>curl.exe -vk 

В выводе curl смотрите на SSL handshake и сообщения вроде certificate problem, verify failed или обрыв на reverse proxy - при этом TcpTestSucceeded уже мог быть True. Пользователь при этом видит предупреждение браузера, а не «сервер не найден».

Если сервер 1С на Linux, с админской машины Windows tnc до host:port всё ещё подходит. На Линух-узле параллельно: ss -tlnp с grep на 1541, с другой машины сегмента - nc -zv host port. Этого хватает, чтобы понять «слушает / не слушает», без отдельной статьи по Linux.

Успешный TCP лишь подтверждает, что порт принимает соединение. Ошибки базы, OData и логина это не отменяет; дальше - журналы ragent, IIS, reverse proxy и прикладная диагностика платформы 8.3.

Код 1С через сокеты для такой проверки админу неудобен: нужны права на выполнение в конфигурации - проще tnc с той же машины, где уже открыта консоль администрирования.

Гоните первую проверку с рабочего места, где пользователь видит ошибку. Приложите к заявке вывод tnc: TcpTestSucceeded и время ответа; долгое ожидание перед False часто указывает на фильтрацию или асимметричный маршрут, а не на мгновенный RST.

Традиционный, портабельный или встроенный способ

Где telnet уже включён - хватит его для ручной пробы за секунды без PowerShell. На чужом ПК без прав на компоненты Windows - PsPing или tcping с флешки. На своём сервере или админской станции с PowerShell 4+ - tnc и поле TcpTestSucceeded; Quiet пригоден для тикета и бат-обёрток.

Exe не тащат, результат читается одним полем - удобно с той же станции, где воспроизводится ошибка. Если политика режет PowerShell на клиенте - PsPing с флешки. Telnet остаётся для серверов, где компонент включили годами раньше.

Для памятки хватит telnet, портабельного exe и tnc - без сканеров подсети; nmap для одного порта 1С на продуктиве без согласования с ИБ часто лишний и запрещён.

ICMP могут резать специально - молчание ping не доказывает, что сервис на 1541 мёртв. Успешный TcpTestSucceeded подтверждает только доставку до порта; базу, лицензию и SQL Server он не проверяет. Связка tnc с разных точек и короткий чеклист на сервере помогают отделить «сеть рубит порт» от проблем сервиса, публикации и СУБД.