История изменений

Всё же есть!

Честно скажу, что идея с tunX где адресное пространство фактически в вакууме не даст никакого профита. Особенно в вопросе балансировки. Аналогично можно просто маркировать пакет и навешивать его на cpu и для обычного ethX. Поскольку интерфейс один, то все будет упираться в него, а не в cpu, как кажется. Только раскидаете равномерно пакеты.
Если нужно тупо нагрузить канал, то сойдут алиасы, как я говорил ранее.
Если нужно протестировать нагрузку на ваших tun'ах, то надо написать сначала серверную и клиентские части. И уже по ним гонять трафик.
В твоем случае, ядро через маршрутизацию само делает, то что необходимо. Пишет пакет из того интерфейса откуда оно должно вылететь.
Как решается вопрос в обход rp_filter и минуя маршутизацию через iptables:

iptables -t nat -I POSTROUTING -d 172.17.0.2/16 -o eth3 -j MASQUERADE

Всё же есть!

Честно скажу, что идея с tunX где адресное пространство фактически в вакууме не даст никакого профита. Особенно в вопросе балансировки. Аналогично можно просто маркировать пакет и навешивать его на cpu и для обычного ethX. Поскольку интерфейс один, то все будет упираться в него, а не в cpu, как кажется. Только раскидаете равномерно пакеты.
Если нужно тупо нагрузить канал, то сойдут алиасы, как я говорил ранее.
Если нужно протестировать нагрузку на ваших tun'ах, то надо написать сначала серверную и клиентские части. И уже по ним гонять трафик.
В твоем случае, ядро через маршрутизацию само делает, то что необходимо. Пишет пакет из того интерфейса откуда оно должно вылететь.
Как решается вопрос в обход rp_filter и минуя маршутизацию через iptables:[code]iptables -t nat -I POSTROUTING -d 172.17.0.2/16 -o eth3 -j MASQUERADE[/code]
Предложу улучшенную его версию (для балансировки): создаете алиасы для eth3 и для каждого tunX делаете собственный SNAT (взамен грубого masquerade).