LINUX.ORG.RU
ФорумAdmin

Как с помощью netcat (то бишь nc) протестировать соединение? (эхо-сервер на «той стороне» есть)

 ,


0

1

Есть очень удаленная, очень засекьюренная сеть, в которую можно зайти только с Windows только через Континент.

В этой сети есть сервак с Linux. Нужно протестировать состояние сети до него, погонять пакеты в обе стороны, выяснить сколько держится одно TCP соединение, нет ли разрывов в течении дня.


1. Эхо-сервер

На серваке с Linux запущен эхо-сервер, обрабатывающий одно соединение:

ncat -e /bin/cat -l 1565

Программа ncat - это не nc (т. е. не netcat), впринципе можно было бы использовать и комаду:

nc -l -p 1565 -c 'xargs -n1 echo'

но так и не смог подобрать рабочие опции, так что эхо-сервер сделан через ncat. Он работает. И обрабатыват только одно TCP соединение до его закрытитя, как мне и нужно.


2. Проверка эхо-сервера

Проверку делаю из Windows через NC for Windows.

Сначала пробую вручную:

c:\tools\netcat\nc -i 1 10.10.18.22 1565

Все работает хорошо: ввожу строку, нажимаю Enter, задержка 1 сек, вижу повтор строки.

a
a
bbbbb
bbbbb
123
123

Так можно вводить много строк. Но надо автоматизировать процесс.

Сделал файл counter.txt, состоящий из пронумерованных строк:

1
2
3
4
5

Скармливаю его:

c:\tools\netcat\nc -v -i 1 10.10.18.22 1565 < counter.txt

Вижу, что файл уходит по строкам, одна строка в секунду. Но ответа (повтора) от сервера не вижу.


Вопрос. Как сделать так, чтобы увидеть ответ эхо-сервера?

★★★★★

Ответ на: комментарий от Elyas

Тогда задержка не 1 секунда а 2 секунды.

Проблема в том, что при скармливании файла, не видно, что приходит от сервера.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от zolden

Почему TCP, а не ICMP?

Потому что проблемы с сервером 1С под линухом, который работает по TCP (спонтанно закрываются соединения, хотя на другой площадке проблем небыло).

И теперь нужно выяснить, то ли действительно сервер 1С под линухом тупит (и тогда будет полная ж с переносом сервера на винду), толи есть проблемы с TCP-соединениями (и тогда линух оставляем и ищем крайнего).

Поэтому нужно понять, рвется ли TCP соединение. И продемонстировать разрыв не только в траффике 1С, а и через nc.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Блин, опции -q в виндовой сборке нет:

[v1.11 NT www.vulnwatch.org/netcat/]
connect to somewhere:   nc [-options] hostname port[s] [ports] ...
listen for inbound:     nc -l -p port [options] [hostname] [port]
options:
        -d              detach from console, background mode

        -e prog         inbound program to exec [dangerous!!]
        -g gateway      source-routing hop point[s], up to 8
        -G num          source-routing pointer: 4, 8, 12, ...
        -h              this cruft
        -i secs         delay interval for lines sent, ports scanned
        -l              listen mode, for inbound connects
        -L              listen harder, re-listen on socket close
        -n              numeric-only IP addresses, no DNS
        -o file         hex dump of traffic
        -p port         local port number
        -r              randomize local and remote ports
        -s addr         local source address
        -t              answer TELNET negotiation
        -u              UDP mode
        -v              verbose [use twice to be more verbose]
        -w secs         timeout for connects and final net reads
        -z              zero-I/O mode [used for scanning]
port numbers can be individual or ranges: m-n [inclusive]

Кстати, в линуховом nc тоже нет -q.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

nc -v -i 1 -q -1 10.10.18.22 1565 < counter.txt

Тут видимо дело не в задержке. Потому что на файле

1
2
3
4
5

на числе 5 nc останавливается, но соединение не закрывает, и ждет непонятно чего. То есть, в консоли мы могли бы увидеть:

1
2
3
4
5 - тут ждет
1
2
3
4
5

Но мы не видим этого. То есть, возможно, при скармливании файла в nc, принятые от сервера данные в поток stdin не направляются (как это происходит при интерактивном режиме).

Возможно, это связано с тем, что данные из файла передаются через stdin, а направление ответа сервера в stdin приведет к лавинообразному траффику.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Кстати, в линуховом nc тоже нет -q.

Странно, у меня в Debian в обоих есть. Один какой-то «nc.openbsd», другой «nc.traditional».

i-rinat ★★★★★
()
Ответ на: комментарий от naszar

кстати лорчую. в руки wireshark (или tcpdump), и вперед

Deleted
()
Ответ на: комментарий от naszar

А ты уже поснифал трафик и посмотрел кто именно закрывает соединение?

Вот в этом я вообще не соображаю. Чего я там могу наснифать, чтобы увидеть кто закрывает соединение?

И кроме того, мне нужно показать, что проблемы не только у 1С, но и на других TCP соединениях.

Xintrea ★★★★★
() автор топика

Плюсую вариант с анализатором трафика.
Подними TCP сесссию и снимай дампы на обоих концах

Чего я там могу наснифать, чтобы увидеть кто закрывает соединение?

Увидишь кто шлёт RST

zolden ★★★★★
()
Последнее исправление: zolden (всего исправлений: 1)
Ответ на: комментарий от i-rinat

А ты пробовал перенос строки сделать \r\n вместо \n? Или наоборот, вместо \r\n сделать \n?

Перенос строки в винде \r\n уже содержит \n.

В файле перенос сделан \r\n.

Поэтому поведение виндового nc что с \r\n, что с \n должно быть правильным.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Поэтому поведение виндового nc что с \r\n, что с \n должно быть правильным.

Тогда у тебя всё работает. Должно же работать.

i-rinat ★★★★★
()
Ответ на: комментарий от Xintrea

То чем ты сейчас занимаешься - тестируешь tcp стек линукса на малюсеньком пакете фиксированного размера. Даже если и есть проблемы на твоем сервере - очень мала вероятность что ты их так найдешь. Надо поймать одно соединение от начала до конца и посмотреть что там есть необычного. В конце концов, почему твой 1С сервер не могет послать FIN из-за того что он кривой или ему что-то там почудилось?

Вот в этом я вообще не соображаю.

Вот тебе хорошая оказия начать соображать. Ибо другого пути нет.

naszar
()
Последнее исправление: naszar (всего исправлений: 2)
Ответ на: комментарий от naszar

То чем ты сейчас занимаешься - тестируешь tcp стек линукса на малюсеньком пакете фиксированного размера.

В общем, я быстренько написал на PHP клиента для эхо-сервера, пихаю серверу разные рандомные строки разной длины, сверяю ответ.

Впринципе, этого достаточно чтобы повторить проблему, если она действительно в TCP-шном взаимодействии.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Да ты полную ерунду говоришь.
При скармливании файла ты видишь не то, что уходит, а именно то, что возвращается.
При вводе вручную ты видел сначала эхо своего терминала, потом жал ввод и получал ответ, теперь у тебя ввод не виден.
Чтобы убедиться, модифицируй эхо-сервер так, чтобы он возвращал не ровно то, что получил, а, например, :::<полученное>.

ABW ★★★★★
()
Ответ на: комментарий от ABW

При скармливании файла ты видишь не то, что уходит, а именно то, что возвращается.

Наверное, так и есть. Ну я уже своим клиентом проверяю, рандомными блоками от 128 байт до 100Кб, потому что обмен в 1С идет в XML, и там более длинных пакетов не видел.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от naszar

Надо поймать одно соединение от начала до конца и посмотреть что там есть необычного. В конце концов, почему твой 1С сервер не могет послать FIN из-за того что он кривой или ему что-то там почудилось?

Этого я больше всего боюсь.

Поэтому нужно сначала исключить ошибки самого линуксового TCP стека во всем этом геперсекьюрном окружении.

Xintrea ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.