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

Question

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

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

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

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

Answer 1

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

Answer 2

Вы можете использовать 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