LINUX.ORG.RU
Форум — Admin  

Нужна подсказка по маршрутам + iptables

 ,


0

1

Добрый день, коллеги! Нужна помощь в нубском вопросе: я что-то упускаю в настройке сети и iptables - прошу помочь советом. Задача: есть сервер openvpn, через один интерфейс (eth0) к нему коннектятся клиенты, второй интерфейс (eth1) смотрит на шлюз Ideco. Смысл в том, чтобы клиенты через ВПН лазили в интернет через Ideco (192.168.10.5). Сейчас получается что сервер OpenVPN сам спокойно может выходить через Ideco в интернет, если выключаем клиентам VPN ходить не через Ideco, сразу в интернет, то все отлично работает. Сам Ideco настроен как прозрачный шлюз. Что в настройках я упускаю?

Схема: стучатся клиенты <-> (eth0) Server OpenVPN (eth1) <-> (192.168.10.5) Ideco <-> интернет

Iptables (правила избыточны - ибо открыл все в поиске где косяк): 

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
#-A INPUT -j REJECT --reject-with icmp-host-prohibited
#-A FORWARD -j REJECT --reject-with icmp-host-prohibited
#COMMIT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT

-A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

*nat
:PREROUTING ACCEPT [39:5343]
:POSTROUTING ACCEPT [2:120]
:OUTPUT ACCEPT [3:196]
-A POSTROUTING -s 172.16.45.0/24 -o eth1 -j MASQUERADE
COMMIT


0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eth0
0.0.0.0         192.168.10.5    0.0.0.0         UG    101    0        0 eth1
172.16.45.0     172.16.45.2     255.255.255.0   UG    0      0        0 tun0
172.16.45.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     101    0        0 eth1

При этом когда клиент подключается по OpenVPN он: 1. Видит сервер ВПН 2. Видит внешний шлюз Ideco - 192.168.10.5 3. При трассировке ya.ru (например) дальше сервера VPN пакет не бежит.

Ткните носом где накосячил.

← Postfix за NAT
Windows-VitrBox-(KVM-Вертуальная машина) →
Ответ на: комментарий от iTA05

Изначальная конфигурация конечно не такая была, но вот так тоже не работает: 

-A INPUT -i tun0 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT

-A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

*nat
:PREROUTING ACCEPT [39:5343]
:POSTROUTING ACCEPT [2:120]
:OUTPUT ACCEPT [3:196]
-A POSTROUTING -s 172.16.45.0/24 -o eth1 -j MASQUERADE
COMMIT

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

В FORWARD оставь вот это: 

-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i tun0 -o eth1 -s [подсеть_openvpn] -m conntrack --ctstate NEW  -j ACCEPT
И проверь, чтобы клиенты ходили по тунелю. Подозреваю, сейчас они ни через какой впн не ходят, отсюда и проблемы.

Проверь маршруты на клиентах, вооружись tcpdump-ом и смотри на впн сервере, откуда к тебе приходят.

P.S. входящие/исходящие на eth0 разреши, чтобы клиенты до сервера могли достучаться

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

Вам на другое намекнули 

0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eth0
Это шлюз по умолчанию.
Смущает вот это:

Сейчас получается что сервер OpenVPN сам спокойно может выходить через Ideco в интернет

Точнее не очень вериться. Покажите выхлоп ip ru s и что бы два раза не вставать ip r s table all

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

Сделал так:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT

-A INPUT -i tun0 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT

-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i tun0 -o eth1 -s 172.16.45.0/24 -m conntrack --ctstate NEW  -j ACCEPT
COMMIT

*nat
:PREROUTING ACCEPT [39:5343]
:POSTROUTING ACCEPT [2:120]
:OUTPUT ACCEPT [3:196]
-A POSTROUTING -s 172.16.45.0/24 -o eth1 -j MASQUERADE
COMMIT

tcpdumpом что нашел (смотрел как отдельно по интерфейсам так и по белому адресу клиента): 1. при подключении клиента до интерфейса tun0 ничего доходит 2. eth0 (через который клиент стучится) - пакеты исправно идут, ответа только нет. 3. до eth1 ничего не долетает

Чтобы работало надо править и 

-A POSTROUTING -s 172.16.45.0/24 -o eth0 -j MASQUERADE

Не пойму я как заставить трафик ходить в интернет через eth1 на OpenVPN после авторизации клиента, а возвращать клиенту через eth0...

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

Сутки прошли, а воз и ныне там. Отстаньте от своего фаервола. Для теста разрешите всё и вкл НАТ. Сначала нужно разобраться с маршрутами. Покажите лучше то, что у вас спросили тут Нужна подсказка по маршрутам + iptables (комментарий) . Клиенты и впн-сервер находятся в одной сети или нет? Если нет, то , что для клиента (впн) является дефолтом?

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

Вот остатки что просили)

ip r s table all

default via 192.168.0.1 dev eth0 proto static metric 100
default via 192.168.10.5 dev eth1 proto static metric 101
172.16.45.0/24 via 172.16.45.2 dev tun0
172.16.45.2 dev tun0 proto kernel scope link src 172.16.45.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.113 metric 100
192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.10 metric 101
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 172.16.45.1 dev tun0 table local proto kernel scope host src 172.16.45.1
broadcast 192.168.0.0 dev eth0 table local proto kernel scope link src 192.168.0.113
local 192.168.0.113 dev eth0 table local proto kernel scope host src 192.168.0.113
broadcast 192.168.0.255 dev eth0 table local proto kernel scope link src 192.168.0.113
broadcast 192.168.10.0 dev eth1 table local proto kernel scope link src 192.168.10.10
local 192.168.10.10 dev eth1 table local proto kernel scope host src 192.168.10.10
broadcast 192.168.10.255 dev eth1 table local proto kernel scope link src 192.168.10.10
unreachable ::/96 dev lo metric 1024 error -113 pref medium
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113 pref medium
unreachable 2002:a00::/24 dev lo metric 1024 error -113 pref medium
unreachable 2002:7f00::/24 dev lo metric 1024 error -113 pref medium
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 pref medium
unreachable 2002:ac10::/28 dev lo metric 1024 error -113 pref medium
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 pref medium
unreachable 2002:e000::/19 dev lo metric 1024 error -113 pref medium
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113 pref medium
fe80::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev eth1 proto kernel metric 101 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
unreachable default dev lo proto kernel metric 4294967295 error -101 pref medium
local ::1 dev lo table local proto unspec metric 0 pref medium
local fe80::952d:4a37:994:cad5 dev lo table local proto unspec metric 0 pref medium
local fe80::a32c:7f3f:73fb:555 dev lo table local proto unspec metric 0 pref medium
local fe80::c0c8:d835:124d:d655 dev lo table local proto unspec metric 0 pref medium
ff00::/8 dev tun0 table local metric 256 pref medium
ff00::/8 dev eth0 table local metric 256 pref medium
ff00::/8 dev eth1 table local metric 256 pref medium
unreachable default dev lo proto kernel metric 4294967295 error -101 pref medium

Клиенты и впн-сервер находятся в одной сети или нет? Если нет, то , что для клиента (впн) является дефолтом? ->

В разных. Для клиента марштуром по умолчанию становится сеть ВПН - передается в параметрах соединения. Однако если убрать маршрут на сервере: 

0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eth0
то при соединении сервер просто не может ответить клиенту

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

...без сарказма конечно нельзя... «Покажите выхлоп ip ru s и что бы два раза не вставать ip r s table all» - из этого следует что лучше сразу второй вывод скинуть

 ip ru s
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
Ved_mak
() автор топика
Ответ на: комментарий от Ved_mak

Или лыжи ли я, но по Станиславскому «не верю» что

Сейчас получается что сервер OpenVPN сам спокойно может выходить через Ideco в интернет

вот неверю и все, не должно такого быть, за исключением варианта отключения первого соединения.
Если посчитать что вы наврали то pbr в помощь.

ЗЫ

...без сарказма конечно нельзя... «Покажите выхлоп ip ru s и что бы два раза не вставать ip r s table all» - из этого следует что лучше сразу второй вывод скинуть

Нет, из этого следует что надо выполнить два действия за один отрыв попы от кресла.

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

Сейчас получается что сервер OpenVPN сам спокойно может выходить через Ideco в интернет

вот неверю и все, не должно такого быть, за исключением варианта отключения первого соединения. Если посчитать что вы наврали то pbr в помощь.

Возможно неверно поняли друг друга: я выше писал что если отрубить один маршрут по умолчанию, то выходит в интернет через Ideco, т.е. фактическая возможность есть, марштурами/iptables косяк. Сейчас поняли что не с iptables проблема.

Помогите вылечить маршрутизацию, ибо у меня идеи кончились...

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

Так я и написал pbr (policy based routing) вам в помощь. Ваши варианты гуглятся весьма легко, «интернет два провайдера», «double openvpn»

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

да уж...

Если этак элементарно гуглится, то зачем пытались помочь? И вообще зачем форумы нужны? Чтобы услышать что ты дурачок и «иди в гугл».

И мне кажется что «double openvpn», это все же другая схема: 

Клиент --> OpenVPN-сервер 1 --> OpenVPN-сервер 2 --> Интернет
 Возврат трафика по обратной схеме:
Клиент <-- OpenVPN-сервер 1 <-- OpenVPN-сервер 2 <-- Интернет

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

Если этак элементарно гуглится, то зачем пытались помочь?

Понимаете ли, есть разница между «за тебя все сделать» и «дать направление что нужно делать». Если Вы хотите готовое решение, «скопипастил и готово», для этого есть другой раздел www.linux.org.ru/forum/job/ Если вы хотите разобраться, но у вас что-то не получаеться, то мы всегда рады помочь здесь.
Вот у вас возникла проблема, на основании ваших данных, вам указали куда копать. Это уже часть решения.

ЗЫ Хотя и здесь иногда могут дать «готовое решение», но редко.

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

ЗЫЫ Что бы было понятнее, начните с «двух провайдеров», научите сначала работать только эту часть. А «double openvpn» только по тому что там есть примеры как прописать в скрипт. Осилите первую часть вторая уже понятна будет сама по себе.

anc ★★★★★
()

Попробуйте что-то вроде этого:

ip rule add pref 90 from 172.16.45.0/24 to 172.16.45.0/24 lookup main
ip rule add pref 100 from 172.16.45.0/24 lookup 100
ip route add default via 192.168.10.5 dev eth1 table 100

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

Ога. Ждем следующего вопроса «от клиента ovpn не пингуеться 192.168.0.0/24 и 192.168.10.0/24(зависит от редиректов)»

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

Ved_mak, а почему вообще родилась такая схема и зачем пользакам ходить в инет через ovpn? В чём сакральный смысл?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Postfix за NAT
Admin
Windows-VitrBox-(KVM-Вертуальная машина) →