в brtcl show не видно tun0 что-то. Попробуй добавить вручную:

brctl addif br-lan tap0

Да, забыл ещё добавить настройки интерфейсов на роутере

1. iptables - покажите выхлоп iptables-save
2. Клиенты не виндовые случаем?

маршруты

1. iptables - покажите выхлоп iptables-save

вот

2. Клиенты не виндовые случаем?

нет

маршруты

а что с ними не так?

Ой, блинааа как всего много....хрен прочитаешь :)
Инет вроде работать должен.
Но попробуем начать с локалки

После
102 -A FORWARD -i tun+ -o eth0.2 -m state --state RELATED,ESTABLISHED -j ACCEPT
добавить
-A FORWARD -o tun+ -i br-lan -m state --state RELATED,ESTABLISHED -j ACCEPT

Делаем ping 8.8.8.8 с клиента и смотрим пакеты на нем (клиенте) tcpdump -i tun0 -n icmp - пакеты должны уходить

далее ловим на сервере tcpdump -i tun0 -n icmp - должны прилетать пакеты с клиента уходят, но на сервере tcpdump молчит :-(

оффтоп

tp-link wdr 4300 с openwrt

Не сильно страдаешь из-за отсутствия хардварного ната? Я вот думаю стоит игра свеч или нет... Окологигабит в сети иметь таки хочу. Нужен не часто, но нужен.

Ааа покажите выхлоп с клиента tcpdump -i tun0 -n icmp , мысль есть...

Ааа покажите выхлоп с клиента tcpdump -i tun0 -n icmp , мысль есть...

here

Не сильно страдаешь

вообще не страдаю

Ок, пускаем пинг с клиента и смотрим на сервере tcpdump -i eth0.2 -n port 1194 пакеты появляются ?

Читать портянку сложно, Вот настройки iptable - пингование сетки за NAT c сервером на шлюзе идет:

iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -o tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

# Если с локалки вылазят в сеть, то ненужно 
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Еще попробуй для эксперимента поменять протокол на tcp, udp может теряться...

Я НИХ<censored>Я НЕ ПОНЯЛ

А 10.0.0.1 хоть пингуется ?

к сожалению, нет

На всякий случай уточню вот эти пакеты
8 22:28:30.372388 IP 37.73.217.98.35270 > 93.188.36.229.1194: UDP, length 101
появляются только года запускаете пинг? (т.е. это точно пакеты от него а не левые от других сервисов)

Да, Вы правы. К сожалению пакеты сыпятся постоянно, даже когда я ничего не пингую с клиента :-(

В кач-ве теста можно временно в конфиге сервера убрать вот эту строку
push «redirect-gateway def1»
и добавить
push «route 10.0.0.0 255.255.255.0»
После этого пингануть 10.0.0.1 и посмотреть пакетики с интерфейса улетают и прилетают ли они на сервер.

Сделал как Вы сказали. К сожалению, это тоже не работает, от клиента пакеты уходят, но на сервере ничего не появляется.

Подождите. Я говорил про внешние интерфейсы а не tun. Что-то типа этого:
tcpdump -i eth0.2 -n port 1194
Вы точно на них смотрели? И на них есть выхлоп с клиента и отсутствие пакетов на сервере?

Подождите. Я говорил про внешние интерфейсы а не tun. Что-то типа этого:
tcpdump -i eth0.2 -n port 1194

Это понятно.

Вы точно на них смотрели?

Точно.

И на них есть выхлоп с клиента и отсутствие пакетов на сервере?

На них есть какая-то активность, но это явно не клиентские пинги :-(

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

На них есть какая-то активность, но это явно не клиентские пинги :-(

Ступил. А сфига там быть активности на порту vpn да и еще и с клиентского ip ? Должна быть только одна активность пинг пнули, пакеты полетели, перестали пинговать пакеты только раз в «keepalive»

И всетаки сюда покажите при пинге выхлоп tcpdump у клиента и сервера в одно и тоже время и при не запущенном пинге. Чего-то меня смущает ваш ответ... чем не знаю, но вот вся практика показывает что-то вы не договариваете.

Спасибо, что ещё со мной возитесь :) Вот логи сервера при подключении клиента и пингом во внутренюю сеть:

• лог при хендшейке и последующим пингом хоста за роутером
• лог tcpdump'a на сервере
• лог tcpdump'a клиента, пингующего хост за роутером
• лог самого пинга

Я немного про другой tcpdump на клиенте говорил tcpdump -i wlp3s0 -n port 1194 (у вас же на клиенте интерфейс исходящий wlp3s0? )
Хочется понять сам клиент пакеты отправляет через тунель т.е. не то что он их на tun0 отправляет а дальше физически уходят ли они. И пингуйте для начала 10.0.0.1

0.0.0.0/1 via 10.0.0.5 dev tun0
128.0.0.0/1 via 10.0.0.5 dev tun0

Откуда у вас на клиенте вылезли вот эти маршруты?

Понял, вот выхлоп серевера: tcpdump on server вот клиентская часть

Я сделал по совету anc

push «redirect-gateway def1»
и добавить
push «route 10.0.0.0 255.255.255.0»
После этого пингануть 10.0.0.1 и посмотреть пакетики с >интерфейса улетают и прилетают ли они на сервер.

Сейчас у меня такие маршруты

Т.е. пакетики долетают я так понимаю iptables на сервере работает ?
Если да
пооробуйте сделать
-I FORWARD -i tun+ -j ACCEPT
-I FORWARD -o tun+ -j ACCEPT
Хотя блин tcpdump должен был бы и без этого на tun трафик показывать, это уже скорее предположение «с горя»

У вас же это рабочий роутер я правильно понял, т.е. из локалки 192.168.10 народ через него в инет ходит ?

У вас же это рабочий роутер я правильно понял, т.е. из локалки 192.168.10 народ через него в инет ходит ?

Да, всё верно

Т.е. пакетики долетают я так понимаю iptables на сервере работает ?

Другого firewall'a там нет.

Сделал как Вы сказали:

-I FORWARD -i tun+ -j ACCEPT
-I FORWARD -o tun+ -j ACCEPT

пингаю 10.0.0.1 и 192.168.10.1(хост за роутером) пакеты на интерфейсах есть, но реплай не приходит обратно :-(

Бредятина да и только. Честно говоря у меня фантазию клинит. Ощущение что с сервером что-то не так но вот что понять не могу.
И да, после всех шаманств 10.0.0.1 так и не стал пинговатся и на интерфейсе tun0 (сервер) пакетов так и не появляеться, верно же?
Посмотрите еще раз логи (не только openvpn) как на сервере так и а клиенте (но скорее сервер) никакого мата там не возникает?

И еще
ip r s table all
на сервере покажите

Можете показать актуальную конфигурацию?
На роутере предварительно поставьте iproute:

opkg update; opkg install ip

# ip -4 addr; ip -4 route list table all type unicast; iptables-save; sysctl -a 2>/dev/null | grep forward

FYI это push «redirect-gateway def1»
openvpn не меняет дэфроут он создает два маршрута которые фактически тоже самое, но за счет маски пакеты летят через впн. Это описано в мане весьма подробно что именно каждая из опций redirect-gateway делает реально.

И да, после всех шаманств 10.0.0.1 так и не стал пинговатся и на интерфейсе tun0 (сервер) пакетов так и не появляеться, верно же?

да, только на eth0.2 есть активность, но tun0 глухо

Посмотрите еще раз логи (не только openvpn) как на сервере так и а клиенте (но скорее сервер) никакого мата там не возникает?

В логах ничего аномального не вижу. При подключении штук 5 пингов проходит на 10.0.0.1 и потом глухо.

int@sophie ~ $ ping -4 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=229 ttl=62 time=7.97 ms
64 bytes from 10.0.0.1: icmp_seq=230 ttl=62 time=4.76 ms
64 bytes from 10.0.0.1: icmp_seq=231 ttl=62 time=2.49 ms
64 bytes from 10.0.0.1: icmp_seq=232 ttl=62 time=1.73 ms
64 bytes from 10.0.0.1: icmp_seq=233 ttl=62 time=2.03 ms

Во! Возможно это comp-lzo выставите одинаково и на сервере и на клиенте.

На роутере предварительно поставьте iproute

уже стоит

Потом на OpenVPN-сервере и клиенте выполните одной строкой

сервер клиент

И еще
ip r s table all
на сервере покажите

показываю

Во! Возможно это comp-lzo выставите одинаково и на сервере и на клиенте.

он вообще везде выключен

К сожалению, отбой ☹ Адрес 10.0.0.1 пингуется с любой машины, не подключенной к vpn

Во! Возможно это comp-lzo выставите одинаково и на сервере и на клиенте.

он вообще везде выключен

А в конфиге клиента в шапке этого нет.

Эмм поподробнее плиз, вроде речь только про клиента идет, т.е. это один штук, а не " любой машины".

Вот как надо :https://geektimes.ru/post/274476/

Влиять не должно, но ip_forward на клиенте попробуйте в 1 выставить.

Покажите с клиента после подключения:

ping -c3 -w8 192.168.10.17; tracepath -n -m5 192.168.10.17; ping -c3 -w8 10.0.0.1; tracepath -n -m5 10.0.0.1