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

13609
heavyd

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

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

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

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

8

2 ответа на вопрос

2
pbr

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

так что это принятый ответ сейчас, но мы не знаем, какой из советов оказался полезным :( törzsmókus 11 лет назад 3
1
Andrey Arapov

You can use socat for that. It has very nice option fork:

fork After establishing a connection, handles its channel in a child process and keeps the parent process attempting to produce more connections, either by listening or by connecting in a loop (example).

Client (yes this you run from the client):

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

Client:

$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753 
$ dig @127.0.0.1 google.com

Похожие вопросы