Возможность предоставления интернета клиентам локальной сети находящимся за клиентом Openvpn

Создать на этом клиенте интернет шлюз, как если бы это был не виртуальный интерфейс, а реальная сетевая карта.

Просто так создание шлюза не работает.

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination

1 0 0 ACCEPT all — enp3s0 tun0 172.30.0.0/24 anywhere

2 0 0 ACCEPT all — tun0 enp3s0 anywhere 172.30.0.0/24

iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -o tun0 -j SNAT –to-source 10.8.0.3

10.8.0.1 - адрес OpenVPN сервера

10.8.0.3 - адрес OpenVPN клиента

172.30.0.1 - enp3s0 (сетевая карта смотрящая в локальную сеть за OpenVPN клиентом)

172.30.0.2 - адрес второго компьютера в локальной сети за OpenVPN клиентом.

Сеть 10.8.0.0 недоступна из сети 172.30.0.0 не хватает маршрутов для того чтобы появился интернет в локальной сети?

такой функционал доступен только в платной версии openvpn. вангую все кончится как обычно мостом в который воткнули вообще все а некотрые сети даже дважды.

А какой маршрут по умолчанию на компьютере? Плюс наверное лучше использовать не SNAT, а MASQUERADE

Выглядит корректно. Покажи cat /proc/sys/net/ipv4/ip_forward и ip r s на openvpn клиенте.

netstat -nr Таблица маршутизации ядра протокола IP Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0

8.8.4.4 172.16.16.1 255.255.255.255 UGH 0 0 0 enp4s0

8.8.8.8 172.16.16.1 255.255.255.255 UGH 0 0 0 enp4s0

10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

128.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0

172.16.16.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0

172.16.16.1 172.16.16.1 255.255.255.255 UGH 0 0 0 enp4s0

172.16.16.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp4s0

172.30.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0

/home/mvt# cat /proc/sys/net/ipv4/ip_forward

1

/home/mvt# ip r s

0.0.0.0/1 via 10.8.0.1 dev tun0

8.8.4.4 via 172.16.16.1 dev enp4s0 proto dhcp src 172.16.16.2 metric 100

8.8.8.8 via 172.16.16.1 dev enp4s0 proto dhcp src 172.16.16.2 metric 100

10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.3

128.0.0.0/1 via 10.8.0.1 dev tun0 172.16.16.0/24 dev enp4s0 proto kernel scope link src 172.16.16.2 metric 100

172.16.16.1 via 172.16.16.1 dev enp4s0

172.16.16.1 dev enp4s0 proto dhcp scope link src 172.16.16.2 metric 100

172.30.0.0/24 dev enp3s0 proto kernel scope link src 172.30.0.1

Также, для доступа в сеть клиента в файл server.conf (OpenVPN) добавлена строка: push «route 172.30.0.0 255.255.255.0»

И, может, как рекомендует nebularia вместо SNAT использовать MASQUERADE?

И, может, как рекомендует nebularia вместо SNAT использовать MASQUERADE?

Ни в коем случае, это один из дибильнейших советов.

0.0.0.0/1 via 10.8.0.1 dev tun0 128.0.0.0/1 via 10.8.0.1 dev tun0

Это с какой-то целью сделано?

Ну а интернет не работает, видимо, из-за днс, он у тебя не натится. Добавь: iptables -t nat -A POSTROUTING -o enp4s0 -j SNAT --to-source 172.16.16.2

Либо на маршрутизаторе (тот который 172.16.16.1) добавь ip r a 172.30.0.0/24 via 172.16.16.2 Логику, надеюсь, понял.

Также, для доступа в сеть клиента в файл server.conf (OpenVPN) добавлена строка: push «route 172.30.0.0 255.255.255.0»

Строка не имеет смысла без iroute, плюс вы делаете SNAT, то есть изначально настраиваете, что будет только соединение от 172.30.0.2 к OpenVPN-северу, но не наоборот.

На 172.30.0.2 маршрут по умолчанию прописан?

0.0.0.0/1 via 10.8.0.1 dev tun0 128.0.0.0/1 via 10.8.0.1 dev tun0

Это следствие, как я понимаю, параметра def1 строчки

push «redirect-gateway def1 bypass-dhcp»

в файле server.conf

А, взято это с перевода книги OPENVPN (https://translaster.github.io/Osvoenie-OpenVPN) раздела «Перенаправление шлюза по умолчанию»

Вот маленькая выдержка:

Перенаправление шлюза по умолчанию достигается добавлением строки push “redirectgateway [def1 local bypass-dhcp bypass-dns]” в файл конфигурации сервера.

Параметр def1: вместо замены существующего шлюза по умолчанию - OpenVPN добавит два новых маршрута, 0.0.0.0/1 и 128.0.0.0/1. Эти маршруты вместе также охватывают все пространство IPv4 и являются более конкретными (/1), чем обычный шлюз (/0). Маршрутизация всегда происходит по более конкретным маршрутам, и, таким образом, весь трафик передается через VPN. Преимущество этого трюка в том, что шлюз по умолчанию остается без изменений. Если VPN-соединение останавливается - исходный шлюз можно восстановить. Обратите внимание, что в этом случае OpenVPN добавит явный маршрут к самому серверу OpenVPN - поэтому сам зашифрованный трафик не будет отправляться через туннель.

Параметр def1 я убрал, маршруты 0.0.0.0/1 128.0.0.0/1 исчезли.

iptables -t nat -A POSTROUTING -o enp4s0 -j SNAT –to-source 172.16.16.2 интернета компьютеру в сети клиента не добавило.

Печаль.

Как бы ему этот DNS присунуть, хотя бы насильно, чтобы понять что дело в нём.

Как бы ему этот DNS присунуть

Дак вы бы сначала по ip-адресам проверял, что ping или ещё что работает, чтобы DNS вобще не использовался для проверок.

В файле CCD клиента OpenVPN строчка

iroute 172.30.0.0 255.255.255.0

есть

А, вот маршрут по умолчанию…..ээээ вроде как нет… Можно подсказку как это сделать?

Вроде?

На компьютере 172.30.0.2 должен быть маршрут по умолчанию через 172.30.0.1, как он добавляется зависит от операционной системы.

С 172.30.0.2 пингуется 10.8.0.3?

Нет, не пингуется, нужен маршрут!!!

ip route add default via 172.30.0.1

Спасибо Вам огромное!

Заработало!