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

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

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

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

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

Так что есть несколько вещей, называемых netcat; У Ubuntu даже есть / etc / alternatives символическая ссылка-хакерство для него.

Я думаю, что часть вашей проблемы заключается в том, что UDP не выполняет сессии; Я скопировал часть файла /usr/share/doc/netcat-traditional/README.gz ниже, который довольно неплохо объясняет.

Соединения UDP открываются вместо TCP, если указан параметр -u. На самом деле это не «соединения», так как UDP - это протокол без установления соединения, хотя netcat использует механизм «подключенного UDP-сокета», который поддерживается большинством ядер. Хотя netcat утверждает, что исходящее 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