Netcat припиняє прослуховування трафіку UDP

Я використовую netcat на деяких машинах Linux (див. Це інше питання ), але бачу деяку несподівану поведінку.

На відміну від керівництва у прийнятій відповіді, я не використовую тунелювання UDP для виконання запитів DNS. У мене є віддалений сервер, на який я можу ввійти, але не встановлювати програмне забезпечення, і я намагаюся тунелювати трафік UDP з мого комп'ютера на сервер, а потім налаштувати окремий тунель, щоб відправити відповіді UDP з сервера на мою машину .

Тунель, що йде від моєї машини до сервера, працює чудово, проте на стороні сервера екземпляр netcat, який слухає відповідь з сервера UDP, закриє слухача після отримання першої відповіді. Тож я можу надіслати запит і отримати 1 відповідь назад, але будь-які наступні запити роблять це на сервері нормально, але відповіді не отримуються. Використовуючи netstat, я бачу, що до отримання відповіді netcat прослуховується, але порт закривається після отримання відповіді.

Екземпляр netcat на моїй машині, здається, справляється з усім просто чудово. На обох машинах працює netcat v1.10-38. Якісь ідеї, що відбувається?

Отже, є кілька речей, які називаються netcat; ubuntu навіть має / etc / alternative символічно-посилання-хакерство для нього.

Я думаю, що вашою проблемою є те, що 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