LINUX.ORG.RU

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

Исправление kostik87, (текущая версия) :

Мне нужно перекидывать всё с tun0 на на eth0

Это как-то не так звучит, тем более имеет другое значение, отличное от:

чтобы клиенты openvpn могли работать с сервисами eth0

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

Как-то так:
чтобы клиенты openvpn могли работать с сервисами в локальной сети за шлюзом, например 192.168.10.0\24.

В таком случае можно просто проложить маршрут через IP адрес OpenVPN шлюза до сети 192.168.10.0\24, в конфиг OpenVPN сервера нужно добавить строку прокладки маршрута: 

push   "route 192.168.10.0 255.255.255.0"
и на шлюзе разрешить просто продвижение пакетов (ip_forward) и forwarding до OpenVPN сети с выходным интерфейсом tun0 и до сети 192.168.10.0\24 с входным интерфейсом tun0.

Но в этом случае на машинах в OpenVPN сети не должно быть пересечения с их локальными сетями. Т.е. если у них их локальная внутренняя сеть будет тоже 192.168.10.0\24, то работать ничего не будет. Но такая сеть маловероятна.

В таком случае клиенты из OpenVPN сети и узлы в локальной сети будут «видеть» себя напрямую.

Если этого не нужно, то опять таки нужно, что бы OpenVPN сервер выдавал клиентам маршрут до локальной сети за шлюзом, но нужно прописать правило NAT (MASQUERADE) для OpenVPN сети.

Т.е., если OpenVPN сеть 192.168.20.0\24, то нужно добавить правило: 

-A POSTROUTING -s 192.168.20.0\24 -o eth0 -j MASQUERADE
в таком случае OpenVPN клиенты смогут подключиться к узлам в локальной сети за шлюзом, но узлы в локальной сети не будут «видеть» узлы в OpenVPN сети.

Но должен быть прописан маршрут на OpenVPN клиентах, как это делается я привёл.

В iptables важна очерёдность правил, если пакет при прохождении таблицы (цепочки) подпадает под какое-либо правило, то он выходит из этой таблицы (цепочки) и другими правилами в таблице уже не обрабатывается.

Исходная версия kostik87, :

Мне нужно перекидывать всё с tun0 на на eth0

Это как-то не так звучит, тем более имеет другое значение, отличное от:

чтобы клиенты openvpn могли работать с сервисами eth0

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

Как-то так: 

чтобы клиенты openvpn могли работать с сервисами в локальной сети за шлюзом, например 192.168.10.0\24.

В таком случае можно просто проложить маршрут через IP адрес OpenVPN шлюза до сети 192.168.10.0\24, в конфиг OpenVPN сервера нужно добавить строку прокладки маршрута: 

push   "route 192.168.10.0 255.255.255.0"
и на шлюзе разрешить просто продвижение пакетов (ip_forward) и forwarding до OpenVPN сети с выходным интерфейсом tun0 и до сети 192.168.10.0\24 с входным интерфейсом tun0.

Но в этом случае на машинах в OpenVPN сети не должно быть пересечения с их локальными сетями. Т.е. если у них их локальная внутренняя сеть будет тоже 192.168.10.0\24, то работать ничего не будет. Но такая сеть маловероятна.

В таком случае клиенты из OpenVPN сети и узлы в локальной сети будут «видеть» себя напрямую.

Если этого не нужно, то опять таки нужно, что бы OpenVPN сервер выдавал клиентам маршрут до локальной сети за шлюзом, но нужно прописать правило NAT (MASQUERADE) для OpenVPN сети.

Т.е., если OpenVPN сеть 192.168.20.0\24, то нужно добавить правило: 

-A POSTROUTING -s 192.168.20.0\24 -o eth0 -j MASQUERADE
в таком случае OpenVPN клиенты смогут подключиться к узлам в локальной сети за шлюзом, но узлы в локальной сети не будут «видеть» узлы в OpenVPN сети.

Но должен быть прописан маршрут на OpenVPN клиентах, как это делается я привёл.

В iptables важна очерёдность правил, если пакет при прохождении таблицы (цепочки) подпадает под какое-либо правило, то он выходит из этой таблицы (цепочки) и другими правилами в таблице уже не обрабатывается.