TUN/TAP записывает обратно в туннель

Мое приложение использует TUN, скажем, tun0. В дизайне мое приложение получит UDP, который включает в себя полный IP-уровень, затем я уберу IP-уровень, а затем использую «запись файла», чтобы поместить их в свое собственное устройство tun0, предположительно в дизайне, я должен прочитать снова отправить пакет из tun0.

Теперь ситуация такова, что через tcpdump я вижу, что пакет записывается в туннель, но я не могу их прочитать обратно.

Что-то не так с настройкой туннеля или маршрута?

заранее спасибо

Ян


tun
person Yang    schedule 15.10.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Ваш второй tun0 не является очередью FIFO. У вас может быть проблема в вашем дизайне, как и почему вы используете второе устройство tun0. Уточните, почему вы его используете и какой процесс должен читать. Правильный подход должен вытекать из этого разъяснения.

Если вы хотите прочитать данные, которые вы отправляете, у вас есть несколько вариантов.

  • Подключите tun0 к эхо-сервису TCP или UDP при его открытии. Это затем отправит вам обратно пакеты, которые вы в него запихнули.
  • Откройте прослушиватель для второго tun0, к которому нужно подключиться. Затем подключитесь к нему и отправьте пакеты из этого соединения. Прочитайте ваши данные со стороны слушателя.
  • Откройте канал с двумя файловыми дескрипторами. Запись в один дескриптор и чтение из другого. Каналы часто используются для IPC (межпроцессного взаимодействия) при разветвлении дочерних процессов.
  • Создайте сокет и считывайте из него данные. Откройте другой конец гнезда для записи. Сокеты часто используются, чтобы позволить другим процессам взаимодействовать с процессом. Это хорошо работает, когда время жизни вызывающего процесса может отличаться от времени жизни слушающего процесса.
  • Создайте буфер или очередь в памяти для хранения данных.
person BillThor    schedule 15.10.2012
comment
En, я использую способ, аналогичный второму варианту: во время инициализации я открываю дескриптор файла, например, tunfd, соединяющий tun0, затем помещаю его в epoll для прослушивания любых входящих. После того, как я запишу IP-пакет, предположительно, как только я получу какой-либо сигнал от epoll, я перейду к чтению пакета из tun0, прочитав tun0. Метод правильный? - person Yang; 16.10.2012
comment
Кстати, я использую один и тот же tun0 для записи и чтения. Я предполагаю, что пакет может вернуться к tun0, а не быть отправленным физически. - person Yang; 16.10.2012
comment
Вы уверены, что открываете туннельное соединение, а не канал с именем tun0? Если вы действительно используете сетевой туннель, вам следует настроить IP-соединение перед его использованием. - person BillThor; 16.10.2012
comment
Эн. Да, перед использованием tun0 я привязывал к нему один IP. Он работает нормально, когда пакеты приходят извне. Проблема в том, что когда я пытался записать пакет в файл на устройство tun0, а затем прочитать его обратно при чтении файла, он не работает. strerr(errno) говорит, что ресурс временно недоступен. Похоже, что обратная петля в tun0 не работает. - person Yang; 16.10.2012
comment
@ Yang tun0 обычно не является петлевым устройством. Когда вы пишете на tun0, другой конец должен читать их, а не вас. Я переписал свой ответ выше. Тот факт, что вы можете или могли бы использовать tun0 в качестве FIFO, не делает его хорошей идеей. - person BillThor; 17.10.2012
comment
Эн. Хорошая точка зрения. Причина, по которой мне нужно записать пакет в tun0, заключается в том, что в моих iptables есть natings. Мне нужно, чтобы пакет ответов прошел через таблицу nat, чтобы преобразовать адрес сервера в IP в его исходный адрес, к которому предположительно хочет подключиться мой клиент. Предположительно, обратная запись в tun0 может позволить пакету пройти через таблицу natting, не так ли? - person Yang; 17.10.2012
comment
@Yang Вы можете отправлять ответы клиенту через то же соединение на tun0. Использование другого подключения не будет делать то, что вы хотите. Реальный (или удаленный NAT) адрес клиента находится во входящих данных соединения. - person BillThor; 17.10.2012
comment
Более. Я связал IP и сокет UDP с файлом tun0. Файловый дескриптор tun0 используется для чтения и записи пакетов, но не привязан к сокету UDP. Я поместил файловый дескриптор tun0 в epoll. На самом деле я могу читать пакеты, если они физически находятся снаружи по IP-адресу, привязанному к tun0. Но когда мое приложение записывает пакеты в tun0, оно не работает при попытке прочитать их обратно. - person Yang; 17.10.2012
comment
@Yang Так и должно работать. Другой конец должен читать то, что вы пишете. - person BillThor; 19.10.2012
comment
Лучше установить rp_filter=2 (свободный режим), мне достаточно. - person Yang; 22.10.2012