Netcat прекращает прислушиваться к трафику UDP
Я использую netcat на некоторых машинах Linux (см. этот другой вопрос), но видящий некоторое неожиданное поведение.
В отличие от руководства в принятом ответе, я не использую UDP, туннелирующий, чтобы сделать запросы DNS. У меня есть удаленный сервер, в который я могу войти, но не устанавливать программное обеспечение на, и я пытаюсь туннелировать трафик UDP со своего компьютера на сервер и затем установить отдельный туннель для передачи ответов UDP обратно с сервера на мою машину.
Туннель, идущий с моей машины на сервер, работает отлично, однако на стороне сервера, экземпляр netcat, который прислушивается к ответу с сервера UDP, закроет слушателя после получения первого ответа. Таким образом, я могу отправить запрос и вернуть 1 ответ, но любые последующие запросы добираются до сервера хорошо, но ответы не получены. Используя netstat I видят, что, прежде чем ответ получен, netcat слушает, но порт затем закрывается после того, как ответ получен.
netcat экземпляр на моей машине, кажется, обрабатывает все очень хорошо. Обе машины выполняют netcat v1.10-38. Какие-либо идеи, что продолжается?
1 ответ
Таким образом, существует несколько вещей, названных netcat; человечность даже имеет/etc/alternatives хакерство символьной ссылки для него.
Я думаю, что часть Вашей проблемы - то, что UDP не делает сессий; я скопировал в части файла/usr/share/doc/netcat-traditional/README.gz, ниже которого делает довольно хорошее задание объяснения.
Соединения UDP открыты вместо TCP, когда-u указан. Это не действительно "соединения" по сути, так как UDP является протоколом без установления соединения, хотя netcat действительно внутренне использует "подключенный механизм" сокета UDP, который поддерживает большинство ядер. Хотя netcat утверждает, что исходящее соединение UDP сразу "открыто", никакие данные не отправляются, пока что-то не читается из стандартного входа. Только после этого это возможный определить, существует ли действительно сервер UDP на другом конце, и часто Вы просто не можете сказать. Большинство протоколов UDP использует тайм-ауты и повторения, чтобы сделать их вещь и во многих случаях не потрудится отвечать вообще, таким образом, необходимо указать тайм-аут и надежду на лучшее. Вы вытащите больше из соединений UDP, если стандартный вход будет питаться из источника данных, которые похожи на различные виды запросов к серверу.
Хорошо поэтому, возможно, это не весь настолько большое из объяснения, но это - то, что я мог найти.
Если бы Вы еще не имеете, Вы могли бы хотеть экспериментировать с любыми netcat опциями, можно найти, что это имело бы отношение к ожиданию... имеют Вас, экспериментировал с:
с помощью-l, а также-u для обеспечения Вы находитесь в режиме "слушания"
- vv для наблюдения точно, что происходит
- q-1..., который должен "ожидать навсегда" даже после получения EOF (надо надеяться, слушая снова?)