OpenVPN LEDE openwrt

У клиента в конфиге openvpn должны быть такие записи:

route-gateway 10.0.100.1
route 192.168.1.0 255.255.255.0

10.0.100.1 это виртуальный ip твоего openvpn сервера

route 192.168.1.0 255.255.255.0 - это пропишет маршрут у клиента в сеть openvpn-а твоей внутренней сети.

На шлюзе на котором запущен openvpn сервер на сетевом фильтре должен быть проброс во внутреннюю сеть из сети openvpn. Например на этом шлюзе интерфейс openvpn tap0, а интерфейс внутренней сети eth1, тогда надо добавить такие правила:

iptables -I FORWARD 1 -i tap0 -o eth1 -p tcp -s 10.0.100.0/24 -d 192.168.1.0/24 -m multiport --source-port 1024:65535 -m multiport --destination-port XXXXXXX -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -i eth1 -o tap0 -p tcp -s 192.168.1.0/24 -d 10.0.100.0/24 -m multiport --source-port XXXXX -m multiport --destination-port 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Вместо XXXXXXX через запятую поставь порты которые ты хочешь увидеть у клиентов во внутренней сети со своей Openvpn сети, например: 136:139,445,3389

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

Далее у клиентов во внутренней сети маршрут по умолчанию должен быть прописан к этому шлюзу на котором запущен Openvpn сервер, если это не так то тогда на шлюзе с Openvpn сервером надо ещё нат настроет по выходу что бы обратка в сеть пошла а не на другой шлюз - который у тебя по умолчанию будет у клиентов прописан.

iptables -t nat -I POSTROUTING 1 -o eth1 -p tcp -s 10.0.100.0/24 -d 192.168.1.0/24 -j SNAT --to-source 192.168.1.254

Где 192.168.1.254 внутренний ip адрес (на интерфейсе eth1) твоего шлюза с openvpn сервером.

Для udp, icmp по аналогии.

Ещё если в ядре по умолчанию выключен форвардинг надо в файле:

/etc/sysctl.conf

прописать

net.ipv4.ip_forward=1

Потом выполнить:

sysctl -p /etc/sysctl.conf

или

echo 1 > /proc/sys/net/ipv4/ip_forward

Вроде бы всё, должно заработать.

Что то мало инфы дал.. route add -net 192.168.1.0/24 gw 10.0.0.2

ГДЕ 192.168.0.0/24 - сеть за маршрутизатором.. ГДЕ 10.0.100.1 - ШЛЮЗ через который видна эта сеть...

Соблюдай разрядность сети,не знаю что у тебя там 32 а может 16..

ifconfig
route

И вообще откуда куда ты попадаешь сложно сказать, между чем и чем у тебя там сеть VPN может два маршрутизатора? может на одной стороне Linux ? Какой ты юзаеш драйвер tup\tun ?

Не внутренняя сеть маршрутизатора а сеть за маршрутизатором ;-)

У клиента в конфиге openvpn должны быть...

Никто ничего не должен. Без особой необходимости это решается на стороне сервера.

route-gateway 10.0.100.1

А это еще зачем?

На шлюзе на котором запущен openvpn сервер на сетевом фильтре должен быть проброс

Простите кто-кто «должен быть»?

Вот скажите зачем вы приводите правила forward там где вас об этом не спрашивали? В задаче тс хоть что-то об этом сказано? А потом дети читают такие ответы и начинают плодить темы я попробовал «ссыль» но у меня все равно не работает.

В конфиг сервера добавить

push "route 192.168.1.0 255.255.255.0"

iptables -t nat -A POSTROUTING -s 10.0.100.0/24 -j MASQUERADE

По поводу route-gateway, согласен можно не писать.

push «route 192.168.1.0 255.255.255.0»

Это в конфиге сервера, или у меня в конфиге клиента:

route 192.168.1.0 255.255.255.0

Одна из этих записей должна быть обязательно, (или в конфиге сервера - как Вы написали, или в конфиге клиента - как я написал) иначе у клиента не будет прописан маршрут к его внутренней сети через vpn интерфейс - tapX и свою сеть 192.168.1.0/24 он не увидит. Тогда этот маршрут можно прописать вручную.

Но что бы увидеть свою сеть этого не достаточно, на шлюзе обязательно должен быть проброс - FORWARD с интерфейса tap0 в интерфейс eth1 и обратно, о чём я и написал и привёл правила.

iptables -t nat -A POSTROUTING -s 10.0.100.0/24 -j MASQUERADE

Можно и так написать, но если у вас на интерфейсе eth1 стационарный ip, а не динамический, то лучше делать как я написал:

iptables -t nat -I POSTROUTING 1 -o eth1 -p tcp -s 10.0.100.0/24 -d 192.168.1.0/24 -j SNAT --to-source 192.168.1.254

В подтверждение привожу цитаты из переведённой документации по netfilter

Маскарадинг (MASQUERADE) в основе своей представляет то же самое, что и SNAT только не имеет ключа --to-source. Причиной тому то, что маскарадинг может работать, например, с dialup подключением или DHCP, т.е. в тех случаях, когда IP адрес присваивается устройству динамически. Если у вас имеется динамическое подключение, то нужно использовать маскарадинг, если же у вас статическое IP подключение, то бесспорно лучшим выходом будет использование действия SNAT.

Маскарадинг подразумевает получение IP адреса от заданного сетевого интерфейса, вместо прямого его указания, как это делается с помощью ключа --to-source в действии SNAT. Действие MASQUERADE имеет хорошее свойство - «забывать» соединения при остановке сетевого интерфейса. В случае же SNAT, в этой ситуации, в таблице трассировщика остаются данные о потерянных соединениях, и эти данные могут сохраняться до суток, поглощая ценную память. Эффект «забывчивости» связан с тем, что при остановке сетевого интерфейса с динамическим IP адресом, есть вероятность на следующем запуске получить другой IP адрес, но в этом случае любые соединения все равно будут потеряны, и было бы глупо хранить трассировочную информацию.

Как вы уже поняли, действие MASQUERADE может быть использовано вместо SNAT, даже если вы имеете постоянный IP адрес, однако, невзирая на положительные черты, маскарадинг не следует считать предпочтительным в этом случае, поскольку он дает большую нагрузку на систему.

Взято вот от сюда: https://it.wikireading.ru/14362

Вот скажите зачем вы приводите правила forward там где вас об этом не спрашивали?

Да ТС не просил приводить правила фильтра, написал только о проблеме, что не видит свою сеть. Проблема может быть и в фильтре, вот я и привёл правила, хотел коснуться всех аспектов с которыми могут быть проблемы.

iptables -t nat -I POSTROUTING...

За -I без необходимости тоже принято по наглой рыжей...

-p tcp
Для протоколов udp, icmp сделай аналогично

Не, ну давайте тогда и порты все по отдельности перечислим, типа -p tcp --port 1 «Для остальных портов до 65535 сделай аналогично»

Ваш вариант правильнее с точки зрения указания интерфейсов и сетей, но это уже частности.

В подтверждение привожу цитаты из переведённой документации по netfilter...

С разморозкой и Добро пожаловать в 2017-й год.

За -I без необходимости тоже принято по наглой рыжей...

Если Вы внимательно посмотрите, я указал ip сетей vpn, внутренней сети, в форварде указал порты (по поводу которых Вы иронизируете), что бы в эти правила, так как они получаются в результате опции -I 1 - 2 для обработки первыми, попали только те пакеты которые должны попасть именно в эти правила. Поэтому в данном случае ничего страшного в "-I 1 - 2" нет.

С разморозкой и Добро пожаловать в 2017-й год.

Вы хотите сказать, что из-за того что информация старая, то она уже не верна?

Поэтому в данном случае ничего страшного в "-I 1 - 2" нет.

Вы даете рекомендации по решению проблемы. А не временный вариант для поиска решения. Вот так потом у народа и рождаются копипаст простыни в которых -I с -A перемешено.

Вы хотите сказать, что из-за того что информация старая, то она уже не верна?

Я хочу сказать, что в 2017-ом она не актуальна. С точки зрения работы разницы не заметите. SNAT полезен для точного указания адреса.
По iptables tutorial училось(я в том числе) и учиться овер дофига народу. И вот этот момент snat vs masq все помнят, поэтому до сих пор регулярно всплывают темы snat vs masq насколько актуально, если интересно погуглите.