Openvpn клиент и прокси на одном сервере

Автор dzirtt, 19 августа 2014, 19:28:10

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

dzirtt

Здравствуйте уважаемые знатоки.

Есть домашний сервер на Debian 7. На него установлен deluge с веб-интерфейсом. Сервер находится в 192.168.1.0/24 сети за NAT роутера.
Порты веб-интерфейса и deluge проброшены и смотрят во внешнюю сеть.
При запросе из локальной сети и на внешний интерфейс ISP всё работает, а также внешние сервисы и сам делюг говорит, что порты открыты.
Как только поднимаю openVPN клиент, все соединения из интернет блокируются, делюг и внешние сервисы говорят что порты закрыты, но запросы внутри сети на те же порты проходят нормально.

iptables

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


ip route с включенным OpenVPN


0.0.0.0/1 via 10.106.1.5 dev tun0
default via 192.168.1.1 dev eth0
10.106.1.1 via 10.106.1.5 dev tun0
10.106.1.5 dev tun0  proto kernel  scope link  src 10.106.1.6
*внешний_интерфейс_впн* via 192.168.1.1 dev eth0
128.0.0.0/1 via 10.106.1.5 dev tun0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.41



ip route с выключенным OpenVPN


192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.41



Подозреваю, что нужно прописать маршрут, но какой и куда не подозреваю.)
Заранее спасибо за помощь.

sandaksatru

OpenVPN не блокирует трафик, а при подключении создает маршрут, через который (0.0.0.0/1 via 10.106.1.5 dev tun0) у вас и идёт весь трафик, а 10.106.1.5 уже натит его в интернеть. Вам нужно пробросить порты на этом шлюзе. Какая цель в vpn-сети? Организация подключения только к удаленному серверу, или что-то ещё?

dzirtt

#2
sandaksatru, поднят опенвпн для шифрования трафика и сокс прокси с которым работают клиенты из внутренней сети.
Можно ли создать маршрут, чтобы по умолчанию весь трафик ходил через eth0. Сокс прокси настроен на использование tun0.
Использовать впн для п2п трафика я не планировал.

route add -net 0.0.0.0/1 gw 192.168.1.1 dev eth0

Это не работает.

sandaksatru

Цитата: dzirtt от 19 августа 2014, 21:09:44
Можно ли создать маршрут, чтобы по умолчанию весь трафик ходил через eth0.
Вам как раз нужно убрать этот маршрут. Его скорей всего push'ает вам сервер. Есть ли возможность сменить изменить конфиг на нём? Клиент с помощью какого приложения организован, можете его конфиг выложить?

dzirtt

#4
sandaksatru, Впн арендован у сервиса, поэтому возможности его изменить нет. Может как-нибудь арендую вдс тогда запилю свой.
openVPN:OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Mar 17 2014

Маршрут я убирал. Не помогло.

client.conf
client
dev tun
proto udp
remote *адрес_впн* 1194
resolv-retry infinite
nobind
persist-key
persist-tun
tls-client
auth-user-pass /etc/openvpn/password
comp-lzo
verb 1
reneg-sec 0
cipher BF-CBC
ca /etc/openvpn/ca.crt
cert /etc/openvpn/cleint1.cert
key /etc/openvpn/client1.key
#route-up /etc/openvpn/vpn_up.sh



Может есть иной путь организовать шифрование хттп трафика? Ибо кроме ssh, l2tp+ipsec, openvpn я ничего больше не знаю.

sandaksatru

#5
Цитата: dzirtt от 19 августа 2014, 22:09:45
Маршрут я убирал. Не помогло.
Попробуйте в конфиг клиента добавить
route-noexec
или route-nopull
Все маршруты тогда нужно будет прописывать самому. Но это теоретически, на практике не пробовал как с ней работает. Вот заодно и проверите =)
Цитата: dzirtt от 19 августа 2014, 22:09:45
Может есть иной путь организовать шифрование хттп трафика? Ибо кроме ssh, l2tp+ipsec, openvpn я ничего больше не знаю.
ssl? gre+ipsec?

dzirtt

Разве можно с помощью ссл шифровать весь хттп трафик в том числе и до ресуров не поддерживающих хттпс?
нужно просто, доступное и так сказать юзер-френдли решение.

Ещё протестировал без правила 0.0.0.0\1 некоторые ресурсы открываются, а некоторые нет, при этом порты открыты, но делюга и внешние сервисы считают что они закрыты.

работает

Aug 19 23:05:38 (1408475138) danted[2811]: pass(1): tcp/connect -: 192.168.1.31.18183 -> apis.google.com.443 (517)
Aug 19 23:05:38 (1408475138) danted[2811]: pass(1): tcp/connect -: www.google.ru.443 -> 192.168.1.31.18180 (1368)



не работает

Aug 19 23:10:25 (1408475425) danted[2807]: pass(1): tcp/connect [: 192.168.1.31.18222 -> www.speedtest.net.80
Aug 19 23:10:25 (1408475425) danted[2807]: pass(1): tcp/connect ]: 192.168.1.31.18222 -> www.speedtest.net.80: Network is unreachable


sandaksatru

Цитата: dzirtt от 19 августа 2014, 23:09:28Разве можно с помощью ссл шифровать весь хттп трафик в том числе и до ресуров не поддерживающих хттпс?
Я имел ввиду ssl vpn.

Убрали вручную, или использовали дополнительные опции в конфиге клиента? Как изменилась после этого таблица маршрутизации? Какая служба управляет сетевыми подключениями на машине, на которой вы запускаете openvpn клиент (networking, network-manager?)? Сделайте трассировку до внешних узлов.

dzirtt

sandaksatru,
Путь убрал вручную. Служба networking.


default via 192.168.1.1 dev eth0
10.123.1.1 via 10.123.1.5 dev tun0
10.123.1.5 dev tun0  proto kernel  scope link  src 10.123.1.6
88.150.184.42 via 192.168.1.1 dev eth0
128.0.0.0/1 via 10.123.1.5 dev tun0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.41



speedtest не открывается



traceroute to speedtest.net (216.146.46.11), 30 hops max, 60 byte packets
1  10.123.1.1 (10.123.1.1)  65.948 ms  65.947 ms  65.948 ms
2  * * *
3  109.201.154.254 (109.201.154.254)  83.686 ms  83.382 ms  83.171 ms
4  85.159.239.38 (85.159.239.38)  76.913 ms  76.921 ms 85.159.239.25 (85.159.239.25)  76.925 ms
5  85.159.239.29 (85.159.239.29)  76.928 ms  77.337 ms ae-3.r02.amstnl02.nl.bb.gin.ntt.net (81.20.64.33)  77.717 ms
6  ae-8.r03.amstnl02.nl.bb.gin.ntt.net (81.20.64.113)  77.693 ms ae-3.r23.amstnl02.nl.bb.gin.ntt.net (129.250.2.158)  76.931 ms ae-3.r02.amstnl02.nl.bb.gin.ntt.net (81.20.64.33)  78.495 ms
7  ae-3.r23.amstnl02.nl.bb.gin.ntt.net (129.250.2.158)  79.241 ms ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144)  174.337 ms  170.761 ms
8  ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144)  175.573 ms  175.554 ms  173.258 ms
9  ae-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.4.4)  168.003 ms  170.981 ms ae-8.r23.nycmny01.us.bb.gin.ntt.net (129.250.2.148)  199.071 ms
10  ae-13.r05.nycmny01.us.bb.gin.ntt.net (129.250.4.166)  182.805 ms ae-1.r05.nycmny01.us.bb.gin.ntt.net (129.250.4.69)  175.495 ms ae-8.r23.nycmny01.us.bb.gin.ntt.net (129.250.2.148)  163.539 ms
11  ge-102-0-0-32.r05.nycmny01.us.ce.gin.ntt.net (129.250.192.58)  158.502 ms  160.520 ms ae-1.r05.nycmny01.us.bb.gin.ntt.net (129.250.4.69)  181.846 ms
12  ge-102-0-0-32.r05.nycmny01.us.ce.gin.ntt.net (129.250.192.58)  171.895 ms !X  163.250 ms  160.981 ms !X




google.ru открывается


traceroute to google.ru (195.98.65.157), 30 hops max, 60 byte packets
1  10.123.1.1 (10.123.1.1)  66.136 ms  66.136 ms  66.135 ms
2  * * *
3  109.201.152.30 (109.201.152.30)  89.424 ms 85.159.237.254 (85.159.237.254)  76.671 ms 85.159.236.222 (85.159.236.222)  76.682 ms
4  85.159.239.49 (85.159.239.49)  79.126 ms  79.108 ms  78.888 ms
5  5.104.137.17 (5.104.137.17)  78.129 ms  78.133 ms  78.136 ms
6  ams-ix.retn.net (195.69.145.216)  77.601 ms  77.017 ms  76.954 ms
7  ae0-2.rt.es.voz.ru.retn.net (87.245.233.122)  129.949 ms  129.928 ms  129.620 ms
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *



sandaksatru

Не смотря на удаленный вручную маршрут, пакеты всё равно идут через шлюз за vpn-сервером. Удалите также этот маршрут (128.0.0.0/1 via 10.123.1.5 dev tun0). А ещё всё же попробуйте добавить указанные выше опции в конфиг openvpn клиента (по очереди) и проверить состояние сети. Если команды сработают нормально, и маршруты по умолчанию не будут проходить через удалённый шлюз, вам останется только прописать маршрут до шлюза (10.123.1.1 via 10.123.1.5 dev tun0). Второй вариант: забить на получаемые маршруты от vpn-сервера и заменить их своими. Для этого добавьте в конфиг клиента эти строки:
route 0.0.0.0 128.0.0.0 192.168.1.1
route 128.0.0.0 128.0.0.0 192.168.1.1


Цитата: dzirtt от 19 августа 2014, 23:09:28нужно просто, доступное и так сказать юзер-френдли решение.
Я почему спросил про клиент. По-моему, самое простое решение - в консоли ручками отредактировать конфиг и прописать маршруты. Но оно не юзер-френдли  ;D Самый юзер-френдли клиент для openvpn реализован через плагин к network-manager'у. И в нём, кстати, можно поставить галочку "использовать только для ресурсов этого соединения", и маршрут по умолчанию заменяться не будет, а останется ваш дефолтный.

dzirtt

#10
sandaksatru, У меня на сервере нет гуи ибо я тоже считаю что vi и nano наше всё.
А на счёт самого простого решения, я имел ввиду самую простую по настройке реализацию шифрования хттп, а не настройку опенвпн.
Команды я до этого проверял.
route-noexec

default via 192.168.1.1 dev eth0
10.188.1.5 dev tun0  proto kernel  scope link  src 10.188.1.6
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.41

dzirtt

Цитата: sandaksatru от 20 августа 2014, 09:55:48Удалите также этот маршрут (128.0.0.0/1 via 10.123.1.5 dev tun0)
С этим пакеты с сервера начинают ходить через ип isp. Но через tun0 вообще ничего не идёт. Хотя данте настроен на использование tun0. Страницы просто не грузит.

Цитата: sandaksatru от 20 августа 2014, 09:55:48route 0.0.0.0 128.0.0.0 192.168.1.1
route 128.0.0.0 128.0.0.0 192.168.1.1
в ip route ничего не изменилось. Вы уверены в синтаксисе команд?

Уже задумываюсь над ESXi и 2 дебиан сервера. Один торрент-качалка другой всё остальное. Во всяком случае на вм всё работало.

sandaksatru

#12
Цитата: dzirtt от 20 августа 2014, 16:17:27default via 192.168.1.1 dev eth0
10.188.1.5 dev tun0  proto kernel  scope link  src 10.188.1.6
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.41
Ну вот и отлично, то что вам нужно. Маршруты от сервера автоматом не назначаются.
Цитата: dzirtt от 20 августа 2014, 16:37:04С этим пакеты с сервера начинают ходить через ип isp. Но через tun0 вообще ничего не идёт. Хотя данте настроен на использование tun0. Страницы просто не грузит.
То же самое происходит при ручном удалении маршрутов.
Цитата: dzirtt от 20 августа 2014, 16:37:04в ip route ничего не изменилось. Вы уверены в синтаксисе команд?
Абсолютно. И в результате у вас должен получится эффект равнозначный от обоих вышестоящих действий. Рекомендую тогда пользоваться первым вариантом.

Теперь весь трафик у вас идёт через ваш родной шлюз, а на OpenVPN сервер у вас летят только те пакеты, которые ему адресованы.

Цитата: dzirtt от 20 августа 2014, 16:37:04Хотя данте настроен на использование tun0.
Аааа, у вас прокси-сервер стоит на vpn-клиенте а не на сервере! Сначала не догнал =) И конечно он у вас при таком раскладе не будет работать. Но кажется, я догадываюсь как его можно настроить... Сейчас на работе нет времени, но вечером я потестирую и, если получится, подскажу вам по настройке. Мне самому интересно стало  :)

sandaksatru

В общем, я тут поразмыслил насчёт разных вариантов... Данте я никогда не использовал, и возможностей его не знаю. Но на 99% уверен, что реализовать то, что вы хотите - невозможно (из-за отсутствия в ядре Linux необходимого функционала).

Но можно реализовать иначе и множеством других способов:

1) Не ловить автоматические маршруты с openvpn сервара (лучше первым способом), использовать любой интернет-прокси, но находящийся за ним. На локальном шлюзе (который в то же время является vpn-клиентом) объявить отдельный маршрут до прокси-сервера. Маскарадинг у вас уже будет прописан на шлюзе, за которым стоит o-vpn сервер. А на всех клиентах локальной сети прописать в браузере адрес того прокси. И вуаля - весь http трафик у вас пойдёт шифрованый аж до vpn-сервера.

2) - n) Остальные, наверное, перечислять не буду, так как уже навскидку пяток назову. Если ещё будут вопросы - задавайте. А пока прошу либо пометить тему [решенной], поскольку с OpenVPN мы разобрались. Либо её слегка переименовать и добавить в первый пост подробное описание задачи. Так будет удобней всем последующим посетителям этой темы. Спасибо  :)

dzirtt

sandaksatru, Я так себе всё и представлял.
Платить ещё и за прокси не хочется, а бесплатным доверия нет.

А на счёт вашего варианта. Каким образом запросы будут попадать на сервер с овпн клиентом, если у всех клиентов внутри сети будет настроен прокси во внешней сети?
Сервер находится за нат роутера. Клиенты ходят в сеть через роутер, а не через сервер. Можно маркировать пакеты манглом в цепочке прероутинга и заворачивать на впн, но что-то мне это не нравится.

А подскажите ОС в которой есть функционал позволяющий реализовать такой механизм?
Какие ещё у вас были варианты?

Пока настроил квм с овпн клиентом на сервере, а на самом сервере поднял п2п клиент, но решение хреновое тут я не поспорю.