Пересылка трафика с устройства TUN (бэкэнд C ++) на шлюз по умолчанию


10

Следующая проблема - только часть большего решения, с которым у меня есть проблема. Кажется, все остальные элементы работают до сих пор, поэтому я постараюсь описать очень маленький фрагмент, с которым у меня проблема.

У меня есть машина linux, с tun0 (туннельный интерфейс) и eth0 (witch - мой шлюз по умолчанию в интернет).

Цель: моя цель - получать пакеты, поступающие от tun0, и пересылать их на шлюз по умолчанию. Так что на самом деле довольно простой случай NAT, где я хочу «поделиться» интернетом с tun0, который подделывает физический интерфейс.

Tun был создан с использованием

sudo openvpn --mktun --dev tun0 --user USER
sudo ip addr add 10.2.0.1/24 dev tun0
sudo ip link set tun0 up

Так что у меня есть и работает, я могу пинговать его и т.д. Кроме того, у меня есть приложение C ++, которое подключается к этому устройству TUN, может читать и писать на него. (fti: вот учебник, которому я следовал: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ )

Я сбросил некоторый правильный запрос ICMP (ping) к 8.8.8.8 в байтовый массив в C ++. Теперь, используя свою программу, я записываю ее на устройство tun0. ICMP-запрос имеет

  • source (10.2.0.10) - поэтому ядро ​​знает маршрут обратно (та же подсеть)
  • назначение (8.8.8.8) - DNS от Google
  • правильная контрольная сумма и т. д. (в Wireshark / TShark он отображается правильно на tun0)

Тогда у меня есть следующие маршруты:

iptables -F # flush
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface tun0 -j ACCEPT

И вот я застрял :( Пакет не перенаправляется на gw по умолчанию (tshark видит его только на tun0 как полученное, что я думаю, это правильно)

Чего не хватает? Может быть, какой-то альтернативный подход (но это должно быть сделано с использованием устройства Tun, и я должен быть в состоянии R / W к нему). Дополнительная информация:

  • пересылка включена (/ proc / sys / net / ipv4 / ip_forward)
  • 8.8.8.8 доступен через eth0 (из местного)
  • шлюз по умолчанию правильный (от провайдера через eth0)
  • я попытался отключить rp_tables (echo 0> / proc / sys / net / ipv4 / conf / eth5 / rp_filter)
  • и много других...

Заранее спасибо за любые подсказки!


Я знаю, что этому больше года, но ты с этим справился? У меня точно такая же проблема.
hplbsh

Ответы:


1

Альтернативным решением будет использование. Так bridgeчто вы можете связать свой tun0 с eth0, и вам не понадобится nat или устанавливать ip на tun0, вы просто помещаете IP-адреса из той же подсети eth0 и того же шлюза, который вы используете прямо сейчас, на клиентские туннельные интерфейсы.

Команды для настройки моста:

# brctl addbr br0
# brctl addif br0 eth0 tun0

www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/set-up-the-bridge

Для использования brctl вам необходимо установить bridge-utilsпакет.
Если ваш дистрибутив Ubuntu:aptitude install bridge-utils


1

Недавно я столкнулся с этой проблемой (после того же упоминания статьи в вопросе) и, немного повозившись, обнаружил, что следующая команда включает локальную пересылку пакетов для устройства tun.

echo 1 > /proc/sys/net/ipv4/conf/tun0/accept_local

Я знаю, что уже очень поздно, я просто пишу здесь, чтобы любой, кто сталкивается с той же проблемой, мог получить какую-то помощь.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.