Сетевики нужны и вот почему / forpes.ru

Главная
Сетевики нужны и вот почему

Сетевики нужны и вот почему +41

30.10.2020 09:15

oldadmin 20 13600 Источник

^{Картинка взята из телнет-видео «Звёздных войн»: telnet towel.blinkenlights.nl}

Недавно был пост о том, нужны ли сетевики. До тех пор, пока проверка доступности tcp/ip порта кажется чем-то сложным даже для администраторов БД и AD, сетевики несомненно нужны. Они особенно полезны в тех случаях, когда необходимо понять почему так плохо работает некое клиент-серверное приложение ценой в пароход.

Иногда мало знать ping и traceroute для того, чтобы понять и устранить проблему в сети. Необходимо понимать как работают все звенья в цепи, а сделать это может лишь сетевик. Рассмотрим несколько таких примеров.

Чем Netcat лучше telnet?

Практически всегда, если речь идет о проверке TCP/UDP порта стараются сделать это через telnet и приходится всякий раз просить поставить Netcat. Есть несколько причин, по которым telnet сильно проигрывает. Вот основные причины.

telnet не умеет различать причины недоступности порта. Все, или ничего — connect, либо fail. Netcat может подсказать, в чем проблема. В этом случае все просто, такого порта в состоянии LISTENING нет.
Не умеет в UDP, SCTP и прочие, ничего кроме TCP.
Не имеет опций тайм-аута соединения -w и проверки без подключения -z

Теперь не говорите, что вы не знали и закопайте поглубже telnet.

(1:1004)$ ncat -v -w3 -z some.server 1111
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connection refused.

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

(1:1005)$ ncat -v -w3 -z another.server 1521
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: No route to host.

Бытует мнение, что на Windows нет альтернативы telnet, однако это неверно. Существует штатная утилита Test-NetConnection, которую можно запустить из PowerShell.

Test-NetConnection -ComputerName "www.contoso.com" -Port 80

Linux MIB в помощь

Если ваш сервер вдруг перестал реагировать на внешние раздражители и клиентские запросы стали провисать, не всегда причина в выдернутом сетевом кабеле, или зависших сервисах JBoss/Tomcat. Прежде, чем заводить кейс в тех-поддержку проверьте Linux MIB. Есть множество программ, выдающих статистику ядра Linux по внутренним счетчикам SNMP. Самая распространенная из них все еще netstat.

(1:1006)$ netstat -s
(1:1007)$ nstat -s

Первая утилита более дружелюбна к пользователю, однако показывает не все переменные. Вторая же показывает весь список, однако не содержит никаких подсказок. Подробнее про отличия здесь. SNMP подсистема Linux находится в несколько обветшалом состоянии, из-за чего нужно приложить некоторые усилия для того, чтобы понять смысл и назначение тех, или иных счетчиков. Для сетевика интерес может представлять buffer overrun.

(1:1008)$ netstat -s |grep prune
873 packets pruned from receive queue because of socket buffer overrun
(1:1009)$ nstat -s |grep Prune
TcpExtPruneCalled   873 0.0

Если сервер не справляется с сетевой нагрузкой и буфер сокета перманентно переполнен, тогда ядро будет просто сбрасывать все новые пакеты и счетчик будет расти на глазах. Чтобы исправить эту ситуацию, можно добавить некоторые настраиваемые параметры в файле sysctl.conf. Текущие значения можно увидеть из файловой системы /proc.

(1:1010)$ cat /proc/sys/net/ipv4/tcp_rmem
4096    16384   4194304
(1:1011)$ cat /proc/sys/net/ipv4/wcp_rmem
4096    16384   4194304
(1:1012)$ grep -e tcp_rmem -e tcp_wmem /etc/sysctl.conf
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Три значения параметра tcp_rmem/tcp_wmem обозначает соответственно минимальное, пороговое и максимальное значение. По умолчанию величины выставлены довольно разумно, поэтому менять их без веских оснований не стоит. Чаще всего такая ситуация может возникнуть на сети с пропускной способностью 10 GiB/s. После сохранения изменений в файле sysctl.conf следует выполнить systcl -p. Эта команда запускает системный вызов setsockopt (SO_RCVBUF).

Следует отметить, что буфер setsockopt(SO_RCVBUF), установленный в приложении, будет ограничен значениями, установленными в net.core.rmem_default и net.core.rmem_max и если приложение имеет буфер размером 1 мб, но net.core.rmem_max составляет всего 256 кб, то буфер сокета приложения будет ограничен этим значением.

Диагностика сети с помощью системных вызовов

Для любого сетевика WireShark абсолютно необходимый инструмент отладки, иногда — главный. Не раз и не два только благодаря WireShark удавалось спасти проект в очень сложной ситуации. Но бывают случаи, когда только в системных вызовах ядра можно увидеть сетевую проблему.
В частности отброшенные пакеты нельзя будет увидеть в tcpdump, или WireShark. Зато можно их увидеть в режиме реального времени с помощью tcpdrop из сета bcc-tools. У команды нет никаких опций, просто выполните tcpdrop. Вывод состоит из сокета, статусе соединения и флагах TCP. Далее идет трассировка стека ядра, которая привела к этому сбросу пакета.

(1:1013)$ /usr/share/bcc/tools/tcpdrop
TIME     PID    IP SADDR:SPORT	  > DADDR:DPORT	  STATE (FLAGS)
16:31:07 3103   4  93.184.216.34:443       > 192.168.11.32:36222   ESTABLISHED (PSH|ACK)
	b'tcp_drop+0x1'
	b'tcp_data_queue+0x1e7'
	b'tcp_rcv_established+0x1df'
	b'tcp_v4_do_rcv+0x131'
	b'tcp_v4_rcv+0xad3'
	b'ip_protocol_deliver_rcu+0x2b'
	b'ip_local_deliver_finish+0x55'
	b'ip_local_deliver+0xe8'
	b'ip_rcv+0xcf'
	b'__netif_receive_skb_core+0x429'
	b'__netif_receive_skb_list_core+0x10a'
	b'netif_receive_skb_list_internal+0x1bf'
	b'netif_receive_skb_list+0x26'
	b'iwl_pcie_rx_handle+0x447'
	b'iwl_pcie_irq_handler+0x4d5'
	b'irq_thread_fn+0x20'
	b'irq_thread+0xdc'
	b'kthread+0x113'
	b'ret_from_fork+0x35'

В bcc-tools имеется еще одна очень полезная утилита tcplife, которая показывает параметры TCP соединения, в том числе, длительность сеанса. У этой команды есть некоторые опции.

(1:1014)$ /usr/share/bcc/tools/tcplife -h
...
examples:
    ./tcplife           # trace all TCP connect()s
    ./tcplife -T        # include time column (HH:MM:SS)
    ./tcplife -w        # wider columns (fit IPv6)
    ./tcplife -stT      # csv output, with times & timestamps
    ./tcplife -p 181    # only trace PID 181
    ./tcplife -L 80     # only trace local port 80
    ./tcplife -L 80,81  # only trace local ports 80 and 81
    ./tcplife -D 80     # only trace remote port 80

Просмотр сессий выглядит так.

# ./tcplife -D 80
PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS
27448 curl       100.66.11.247   54146 54.154.224.174  80        0     1 263.85
27450 curl       100.66.11.247   20618 54.154.164.22   80        0     1 243.62
27452 curl       100.66.11.247   11480 54.154.43.103   80        0     1 231.16
27454 curl       100.66.11.247   31382 54.154.15.7     80        0     1 249.95

Может так случится, что между клиентом и сервером расположен межсетевой экран, либо IPS/IDS с набором правил по обрыву длительности TCP сессии по прошествии определенного времени, или достижении некоего объёма трафика. В этом случае диагностика подобного кейса может затянутся неопределенно долго, так как находится в слепой зоне, как со стороны клиентского, так и со стороны серверного приложения. Единственный способ понять в чему тут дело, это использовать инструменты bcc-tools.

Недооцененный резолвинг

Еще одним слепым пятном во многих проектах по внедрению, интеграции различных комплексов автоматизации и повышения производительности, является система разрешения имен ОС. Большинство приложений могут работать с ошибками если не соблюдено следующее условие.

getnameinfo(getaddrinfo(HOSTNAME)) = HOSTMANE

функции getnameinfo и getaddrinfo являются заменой устаревших gethostbyname и gethostbyaddr соответственно.

int getnameinfo(const struct sockaddr *addr, socklen_t addrlen,
    char *host, socklen_t hostlen,
    char *serv, socklen_t servlen, int flags);

int getaddrinfo(const char *node, const char *service,
    const struct addrinfo *hints, struct addrinfo **res);

Положительный пример — lib.ru

(1:1015)$ host lib.ru
lib.ru has address 81.176.66.163
...
(1:1016)$ host 81.176.66.163
163.66.176.81.in-addr.arpa domain name pointer lib.ru.

Отрицательный пример - example.com.
(1:1017)$ host example.com
example.com has address 93.184.216.34
(1:1018)$ host 93.184.216.34
Host 34.216.184.93.in-addr.arpa. not found: 3(NXDOMAIN)

Если бы IP 93.184.216.34 указывал не на example.com, а на иной хост, то и это было бы ошибкой. Только тождество результат двустороннего разрешения имен гарантирует отсутствие ошибок настройки.
Вообще-то используя утилиту host следует помнить, что она так же, как dig и nslookup используют лишь DNS для разрешения имён хостов и игнорируют записи в файле /etc/hosts. По этой причине целесообразнее использовать команду getent.

(1:1019)$ strace -f -e trace=openat host my.router 2>&1 |grep -e "^openat" -e address
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libuv.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/self/task/7164/comm", O_RDWR) = 3

(1:1020)$ strace -f -e trace=openat getent ahosts my.router 
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/libunistring.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib64/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file or directory)
192.168.10.10    STREAM my.router
192.168.10.10    DGRAM  
192.168.10.10    RAW    
+++ exited with 0 +++

Из вывода видно, что host не обращается к файлу /etc/hosts и по этой причине не в состоянии определить IP адрес маршрутизатора. Напротив, getent ищет в этом файле и находит соответствующую запись.

Использованные материалы

Комментарии (20)

Loxmatiymamont
30.10.2020 12:54
#22244782
+1
Вы раскрыли остатки тайных знаний сетевиков и теперь они стали окончательно не нужны.
Спасибо вам!
1. podde
  30.10.2020 14:34
  #22245350
  +3
  Вижу вас не в первом посте, и каждый раз – удивительно токсичные комментарии.
  1. Loxmatiymamont
    30.10.2020 14:42
    #22245398
    -3
    Извините.

usego
30.10.2020 13:37
#22245044
Полезно, спасибо. Но на штатную единицу не тянет :))
1. booyakacrew
  31.10.2020 02:28
  #22247682
  Развертывание/управление SDN добавить и потянуло бы

martin74ua
30.10.2020 16:07
#22245816
+1
Если бы IP 93.184.216.34 указывал не на example.com, а на иной хост, то и это было бы ошибкой. Только тождество результат двустороннего разрешения имен гарантирует отсутствие ошибок настройки.

Спорно. Очень спорно, особенно в случае shared хостинга. Если у меня на сервере 300 сайтов на одном ип — это правило сработает ровно для одного домена. А извне невозможно определить hostname сервера…
1. glowingsword
  31.10.2020 00:36
  #22247486
  +1
  Думаю, всё проще. У вас может быть много доменов с А-записями, указывающими на одни IP, но только одна PTR указывающая на один домен. И вот этот домен должен разрешаться в IP, PTR которого разрешается в этот домен. Если это условие соблюдено(оно для почтовых сервисов важно, к примеру), то проверки некоторых сервисов, проверяющие подобное соответствие, завершаются удачно, если нет – фейлятся. Поэтому всегда соблюдаем простое правило, когда основной домен смотрит на IP, а IP указывает в PTR на этот же домен, и проверка на соответствие PTR у IP, и А-записи у домена будет проходить успешно. Это и есть двустороннее разрешение имён. Другие ваши домены могут смотреть на этот же IP, и их может быть тысячи, это не проблема. Главное не забывать, что есть домен, что должен быть указан в PTR.

zer0nka
31.10.2020 02:38
#22247704
+4
за один только заголовок можно автора забанить

Sergey-S-Kovalev
31.10.2020 07:52
#22247926
+4
На мой взгляд, в статье потребность в сетевиках не раскрыта. Почти все описанное в статье делается и траблшутится типовым админом обслуживающим ОС. Посмотреть слушающие порты, проверить правила фаерволла ОС или антивируса — обыденная рутина при траблшутинге. Что бы поднять условный bind и прописать записи в зоне — знание сетевых протоколов совсем не обязательно. И модель OSI про которую все сетевики говорят, что она не нужна, но всегда про нее спрашивают соискателей, знать не нужно. Даже прописать в микротике вланы, что бы отдельно принять каналы на цифровую телефонию и интернет — это близко, но все еще не сетевик, как и замена электрической розетки дома не делает вас электриком.

Сетевики там где много каналов связи, телефонии, ВКС. Где много L2/L3 VPN в рамках B2B. Когда ты траблшутишь корявую покраску трафика со стороны оператора или почему посреди ВКС кто то начинает роботизированным голосом общаться. Маршрутизация трафика, ограничения на уровне сетевого доступа по портам и протоколам это обыденность в работе сетевика. Принять телефонию от оператора, прогнать через CUCM, выплюнуть в Астериск, что бы хоть как то заработала сказочная облачная телефония от Битрикса. Вот это все сетевики. И без них в таких ситуациях никак.
1. TimsTims
  01.11.2020 04:07
  #22250400
  Зашел сюда ради этого комментария. Теперь тема точно раскрыта.

AkshinM

31.10.2020 21:09

#22249710

Бытует мнение, что на Windows нет альтернативы telnet, однако это неверно. Существует штатная утилита Test-NetConnection, которую можно запустить из PowerShell.

Да, но она не очень удобная если мне надо проеврять много серверов\компьютеров. Если устройства нет в сети, то процесс затянется очень надолго.

А еще штатный telnet, тоже когда не может подключиться, то консоль застревает и CTRL + C или CTRL + ] не обрывает команду.

Поэтому учитвая все это, я написал небольшую утилиту для себя на PowerShell, а за тем конвретировал PS1 скрипт в EXE с помощью утилиты PS2EXE, и поместил исполняемый файл в папку C:\Users\%USER_PROFILE%\AppData\Local\Microsoft\WindowsApps под названием tel.EXE, чтобы можно было вызывать ее из CMD сразу. Плюс к тому же писать telnet дольше чем tel ;).

Утилита обладает следующими качествами:

Если в течение 500 милисекунд не может подключиться, то проверка обрывается
Есть возможность оборвать процесс Ctrl + C
Есть возможность поставить -t в конце команды, для бесконечной проверки заданного порта. Пример: tel server01 443 -t. Анологичен аргументу -t в ping.
Есть функция игнорирования https:// и http:// в начале адреса сервера. Иногда бывает что копируешь ссылку с бразуера для проверки адреса, и в командную строку добавляется с https:// или http://, приходится еще это стирать. С этой функцией не надо запариваться стирать префиксы https:// или http://, она сама их уберет. Пример: tel httрs://server01 8443

Ниже в под спойлером исходный код:

исходный код

function TestServerPort {
    param(
        [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] [string]$ComputerName, #Server DNS name or IP address
        [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] $Port, #Server Port
        [Parameter(Mandatory = $true)] [ValidateNotNullOrEmpty()] $Timeout #Timeout
    )
 
    try {
        $tcpclient = New-Object -TypeName system.Net.Sockets.TcpClient
        $iar = $tcpclient.BeginConnect($ComputerName, $port, $null, $null)
        $wait = $iar.AsyncWaitHandle.WaitOne($timeout, $false)
        if (!$wait) {
            $tcpclient.Close()
            return $false
        }
        else {
            $null = $tcpclient.EndConnect($iar)
            $tcpclient.Close()
            return $true
        }
    }
    catch {
        $false 
    }
}

if ($args.Count -eq 1) {
    $value = $args[0]
    if (($value -eq "/?") -or ($value -eq "?") -or ($value -eq "-?") -or ($value -eq "-h") -or ($value -eq "h") -or ($value -eq "/h")) {
        Write-Host ""
        Write-Host "    ********************************"
        Write-Host "    **                            **"
        Write-Host "    **Created by Akshin Mustafayev**"
        Write-Host "    **                            **"
        Write-Host "    ********************************"
        Write-Host ""
        Write-Host "    This tool tests connection between your computer and the remote server using specified port."
        Write-Host "    List of arguments available for this tool: "
        Write-Host "        -? , /? , ? : Shows help information"
        Write-Host "        -h , /h , h : Shows help information"
        Write-Host ""
        Write-Host "        -t , /t , t : Loops port check. Similar to `"ping your_server -t`" command"
        Write-Host ""
        Write-Host ""
        Write-Host "    Usage examples:"
        Write-Host "        tel -?"
        Write-Host "        tel srv 443"
        Write-Host "        tel srv 443 -t"
        Write-Host ""
        Write-Host ""
        Write-Host "    Press `"Control + C`" to terminate execution of the program."
        Write-Host ""
    }
    break
}

if ($args.Count -ge 2) {
    $server = $args[0]
    $port = $args[1]

    $server = $server.ToString().Replace("https://", "")
    $server = $server.ToString().Replace("http://", "")

    $loop = $null
    if (($null -ne $args[2]) -and ($args[2] -ne "")) {
        $loop = $args[2]
    }
    Write-Host ""
    if (($null -ne $loop) -and (($loop -eq "-t") -or ($loop -eq "/t") -or ($loop -eq "t"))) {
        while ($true) {
            $result = TestServerPort -ComputerName $server -Port $port -Timeout 500

            if ($result) {
                Write-Host "    Connection success $($server):$($port)"
            }
            else {
                Write-Host "    Connection error $($server):$($port)"
            }
            Start-Sleep -Seconds 1
        }
    }
    else {
        $result = TestServerPort -ComputerName $server -Port $port -Timeout 500

        if ($result) {
            Write-Host "    Connection success $($server):$($port)"
        }
        else {
            Write-Host "    Connection error $($server):$($port)"
        }
    }
}
else {
    Write-Host ""
    Write-Host "    Error. Provide required arguments. Example: tel server1 443"
    Write-Host "    Write -? or -h to get help. Example: tel -h"
}

sigmatik
01.11.2020 07:53
#22250528
Не тянет это все на сетевика. Обыкновенные навыки обыкновенного админа в обыкновенном малом / среднем бизнесе. Сетевик это обычно все же Энтерпрайз/ провайдер / оператор связи.

igan
01.11.2020 11:10
#22250774
С точки зрения админа и безопасника устанавливать netcat без особой необходимости на хостах наверное не надо, чтобы не облегчать задачу тому кто захочет каким нибудь 'reverse shell' баловаться.

Eще есть такой аспект что рвать коннект для теста не всегда хорошо для приложения (могут появляться нежелательные ошибки в логах) и утилиты типа tcping более мягко обходятся с сервером. Хотя tcping вроде тоже не может отличить дропнутый фаерволом пакет от не слушающего сервера.

А есть что то менее мощное чем nc чтобы такое диагностировало?
1. tendium
  01.11.2020 11:32
  #22250840
  чтобы не облегчать задачу тому кто захочет каким нибудь 'reverse shell' баловаться.
  Тот, кто получит доступ к хосту для целей reverse shell, разве не сможет залить на сервер свой собственный netcat?
  
  Eще есть такой аспект что рвать коннект для теста не всегда хорошо для приложения (могут появляться нежелательные ошибки в логах)
  Ну, хорошо, мы так делать не будем. Это остановит злоумышленника?
  
  не может отличить дропнутый фаерволом пакет от не слушающего сервера.
  А как технически это отличать?
  1. igan
    01.11.2020 12:07
    #22250934
    Тот, кто получит доступ к хосту для целей reverse shell, разве не сможет залить на сервер свой собственный netcat?
    
    Может но не так просто чем если nc уже там. Можно и однострочник на питоне сделать
    Как и вся другая ИБ эта мера чтобы уменьшить вероятность и усложнить эксплуатацию уязвимости а не исключить ее полностью
    
    Ну, хорошо, мы так делать не будем. Это остановит злоумышленника?
    
    Ну как раз появление странных логов от неаккуратных сканеров может быть хорошим звоночком
    
    А как технически это отличать?
    
    См в статье. Мое скромное понимание в том что фаервол можно сконфигурять 2 варианта ответа
    
    1) REJECT — в этом случае мы говогрим всему миру что тут есть Фаервол и он посылает тебя подальше с явным сообщением что сюда не ходи. Соответсвует как правило 'Connection closed'
    2) DROP — тогда ответ не отличим от отсутствующего сервиса. Ответ не посылается и клиента просто игнорят — нас тут нет. Как правило это скорее показывается как 'Timeout'
    
    Внутри сети обычно хорошие админы и сетевики ставят REJECT чтобы облегчить дебаг и вовне DROP чтобы не облегчать (см выше)
    
    Дислкожа — я не сетевик так что поправляйте если что
    
    tendium
    01.11.2020 13:01
    #22251058
    1) REJECT — в этом случае мы говогрим всему миру что тут есть Фаервол и он посылает тебя подальше с явным сообщением что сюда не ходи. Соответсвует как правило 'Connection closed'
    2) DROP — тогда ответ не отличим от отсутствующего сервиса. Ответ не посылается и клиента просто игнорят — нас тут нет. Как правило это скорее показывается как 'Timeout'
    Ох...

axelk
02.11.2020 12:38
#22253742
Не всегда на нужном сервере есть права на установку, да и телнет клиент на некоторых системах не установлен по умлочанию. Еще про проверку TCP и UDP портов через devfs в линуксе можно упомянуть:
```
cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_8.3
^C
```
или так:
```
< /dev/udp/8.8.8.8/53 || echo "Not OK" && echo "OK"
OK
```
1. fearan
  03.11.2020 13:37
  #22257736
  Это не «в линуксе», это в bash — причем конкретной версии и конкретной сборки.

resetsa
02.11.2020 12:38
#22253744
«Ncat: Connection refused» — скорее скажет о том, что порт не слушается на сервере.
Очень редко FW настраивают на отправку RST в запрос на соединение.
А диагностика сети с использованием strace и анализом трассировки стека — это конечно круто, но больно и сложно.

bang
02.11.2020 12:38
#22253746
getnameinfo(getaddrinfo(HOSTNAME)) = HOSTMANE

Условие так себе, как мне кажется. ;)