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

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

 , ,


1

2

Здравствуйте! Прошу помощи, и, наверное, больше подтверждения, правильно ли я думаю. Ситуация вроде как избитая, но я не справляюсь. По технической реализации сеть должна выглядеть так: Сервер (ubuntu-server): установлен OpenVPN, работает, создает туннель (tun0) с клиентом (тоже ubuntu-server). Интернет на клиенте есть, весь трафик с него завёрнут в туннель, но этот клиент, в свою очередь, должен выступать в роли файлового хранилища, точки WI-FI для клиентов локальной сети которая находится за ним. С организацией локальной сети, WI-FI проблем нет, но вот каким образом раздать от клиента OpenVPN (с интерфейса tun0) интернет в локальную сеть находящуюся за ним? Создать на этом клиенте интернет шлюз, как если бы это был не виртуальный интерфейс, а реальная сетевая карта? Форвадинг пакетов на клиенте включён. Или такое невозможно и я неправильно думаю?


Ответ на: комментарий от t184256

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

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 не хватает маршрутов для того чтобы появился интернет в локальной сети?

mvt
() автор топика

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

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

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

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

/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?

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

И, может, как рекомендует 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 Логику, надеюсь, понял.

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

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

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

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

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

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 присунуть, хотя бы насильно, чтобы понять что дело в нём.

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

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

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

mky ★★★★★
()
Admin