Netcat прекращает прослушивание трафика UDP

Я использую netcat на некоторых машинах Linux (см. Этот другой вопрос), но вижу неожиданное поведение.

В отличие от руководства в принятом ответе, я не использую туннелирование UDP для выполнения DNS-запросов. У меня есть удаленный сервер, на котором я могу войти, но не могу установить программное обеспечение, и я пытаюсь туннелировать трафик UDP от моего компьютера к серверу, а затем настраиваю отдельный туннель для отправки ответов UDP с сервера на мою машину,

Туннель, идущий от моей машины к серверу, работает отлично, однако на стороне сервера экземпляр netcat, который прослушивает ответ от UDP-сервера, закроет слушателя после получения первого ответа. Таким образом, я могу отправить запрос и получить 1 ответ обратно, но любые последующие запросы делают это на сервере, но ответы не принимаются. Используя netstat, я вижу, что до получения ответа netcat прослушивает, но порт после закрытия ответа закрывается.

Экземпляр netcat на моей машине, кажется, справляется со всем просто отлично. Обе машины работают под управлением Netcat v1.10-38. Есть идеи, что происходит?

Источник

2 ответа

Решение

Так что есть несколько вещей, называемых netcat; В Ubuntu даже есть /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 (надеюсь, снова слушать?)

Источник

Ты можешь использовать socat для этого. Это очень хороший вариант fork:

fork После установления соединения обрабатывает свой канал в дочернем процессе и удерживает родительский процесс, пытающийся создать больше соединений, путем прослушивания или соединения в цикле (пример).

Клиент (да это вы запускаете с клиента):

$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"

Клиент:

$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753

$ dig @127.0.0.1 google.com
Источник
Другие вопросы по тегам