LINUX.ORG.RU
ФорумAdmin

openvpn on openwrt router

 ,


0

2

Всем привет. Настроил openvpn на router'е tp-link wdr 4300 с openwrt на борту. Клиент нормально цепляется к роутеру, но не может доступиться к хостам во внутренней сети 192.168.10.0/24 (за роутером), в интернет тоже не ходит. Хочется, чтобы клиент имел доступ к хостам за роутером и мог ходить в интернетики :)

В чём проблема?


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

anc ★★★★★ ()
Ответ на: комментарий от ubik

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

После
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
Теперь инет посмотрите tcpdump-м
Делаем ping 8.8.8.8 с клиента и смотрим пакеты на нем (клиенте) tcpdump -i tun0 -n icmp - пакеты должны уходить
далее ловим на сервере tcpdump -i tun0 -n icmp - должны прилетать
ну и на сервере уже смотрим tcpdump -i eth0.2 -n icmp and host 8.8.8.8

anc ★★★★★ ()
Ответ на: комментарий от anc

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

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

ubik ()

оффтоп

tp-link wdr 4300 с openwrt

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

matrixd ()
Ответ на: оффтоп от matrixd

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

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

ubik ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()

Читать портянку сложно, Вот настройки 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 может теряться...

tyrpyr ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

ubik ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

ubik ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

Это понятно.

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

Точно.

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

anc ★★★★★ ()
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

ubik ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()

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

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

ArcFi ()
Ответ на: комментарий от ArcFi

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

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

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

anonymous ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

Да, всё верно

ubik ()
Ответ на: комментарий от anc

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

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

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

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

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

ubik ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от ubik

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

opkg update; opkg install ip

Потом на OpenVPN-сервере и клиенте выполните одной строкой:
# ip -4 addr; ip -4 route list table all type unicast; iptables-save; sysctl -a 2>/dev/null | grep forward

И выхлоп на https://paste.fedoraproject.org/.

ArcFi ()
Ответ на: комментарий от ArcFi

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

anc ★★★★★ ()
Ответ на: комментарий от anc

И да, после всех шаманств 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

ubik ()
Ответ на: комментарий от anc

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

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

ubik ()
Ответ на: комментарий от ubik

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

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

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

anc ★★★★★ ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от ubik

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

anc ★★★★★ ()
Ответ на: комментарий от ubik

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

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

ArcFi ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.