☰

Сценарий:

tag-icon • tag-icon linux networking routing firewall network-interface
Сценарий:

В итоге

Пакеты, считываемые с интерфейса TUN, не находят свой путь при обратной записи на тот же интерфейс TUN.

В полном объеме

Сценарий:

На машине только с1Сетевая карта (eth0), подключенная к Интернету, я написал приложение, которое считывает IP-пакеты с интерфейса TUN; затем оно может:

  • записать пакет без каких-либо изменений обратно на тот же интерфейс TUN
  • блокировать пакет
  • внести изменения в пакет (например, зашифровать его полезную нагрузку) и записать измененный пакет обратно в интерфейс TUN.

Сделанный:

Я выполнил следующие шаги:

  1. Я запускаю свою программу. Она выделяет и создает экземпляр устройства TUN и ждет, пока устройство будет поднято.

  2. Затем я выполняю следующие команды:

    ifconfig tun0 up ifconfig tun0 10.0.0.2 route add -net 0.0.0.0 netmask 0.0.0.0 dev tun0 echo 1 > /proc/sys/net/ipv4/ip_forward

  3. Теперь моя программа начинает успешно считывать пакеты (и выводить/регистрировать их содержимое).

  4. Моя программа записывает обратно пакетбез каких-либо измененийвернуться к устройству tun0

ПРОБЛЕМА:

Записанный обратно пакет не находит свой маршрут обратно, чтобы пойти, например, на eth0 или на прикладной уровень. Например, когда я выполняю ping:

ping 4.2.2.4

и на другом терминале:

tshark -i tun0

Я вижу, что tun0 видит пакет ICMP echo (тоже моя программа):

 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=2/512, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=3/768, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Unknown ICMP (obsolete or malformed?)

Моя программа записывает пакет обратно в tun0 и tsharkвидит его (в приведенном выше фрагменте)

Но ICMP-запрос не доходитeth0чтобы он мог найти свой путь к 4.2.2.4. IMHO, проблема в правилах маршрутизации, но я не смог найти, как ее изменить.

Любые комментарии приветствуются, С уважением

решение1

конечно, проблема с правилами маршрутизации, вы сказали ядру направлять все пакеты из tun0:). Когда вы отправляете этот пакет обратно на tun0, он снова направляется обратно из tun0, а не eth0. За исключением того, что в вашем случае пакет, похоже, отбрасывается из-за "фильтра обратного пути", т. е. он отказывается отбрасывать пакеты из того же интерфейса, на который они пришли.

Связанный контент