Есть впн сервер на опенвпн. На самом сервере есть два интерфейса ens18 (локальный в сеть с айпи 192.168.0.41) и в интернет ens19 (1.1.1.1). Сам опенвпн может выдавать любой диапазон айпи, НО из подсети 192.168.0.0/24 уже половина занята, поэтому выдается подсеть 10.8.0.0. Задача - чтобы подключаться к впн и видеть локальную сеть 192.168.0.0/24.
Сейчас только видит интернет через правило
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens19 -j SNAT --to-source 1.1.1.1
Также видит 192.168.0.41, но не видит всю локалку 192.168.0.0/24.
Можно конечно, попробовать прописать определенный диапазон айпи из подсети 192.168.0.0/24 для выдачи, но хотелось бы использовать разные подсети.
Также интересно, можно ли впн трафик пустить только для локалки, соответственно, в интернет по прежнему буду выходить через свой интернет.
вам нужна маршрутизация между локальной подсетью и виртуальной подсетью vpn
чтобы впн клиенты (или сайд) ходили в свой интернет самостоятельно - вам нужно убрать натирующее правило, а им (клиентам или сайду\ам) со своей стороны настроить маршруты и метрики соответствующим образом.
Олег Свирчев: такое это какое?
1) на сервере прописать маршруты для локальной и виртуальных сетей.
2) убрать натирующее правило, которое пушит виртуальную сеть в интернет.
3) на клиенте настроить метрики и маршруты, чтобы он не пытался найти интернет на виртуальном интерфейсе (собственно, где его уже нет, после п.2)
4) ....
5) PROFIT!
Олег Свирчев: с выбранными Вами средствами так не получится. приоритет маршрутов и интерфейсов настраивается только на стороне клиента.
если это не настроить, то с наибольшей долей вероятности при пинге с клиента 8.8.8.8 - он полезет в туннель vpn, а там (если убрать правило NAT и как следствие доступ к 8.8.8.8) уже умрёт.
cssman: А что Вы можете сказать по поводу решения от sazhyk У меня просто оно не работает и я не до конца понимаю, почему оно должно работать.
По сути мой кейс очень распространенный, когда сотрудник хочет получить доступ через впн к инфраструктуре компании. Неужели нету изящного решения для этого, чтобы ничего не придумывать. Более того, а что если я захочу еще другие протоколы поднять, например IPsec
Олег Свирчев: это решение - то же самое, что я написал в п.1, но для того, чтобы пользователь, подключившийся к впн серверу лез в Интернет не через туннель - этого не достаточно.
Что именно у Вас не работает? Нету доступности до серой сети, после получения виртуального айпишника? Или в интернет лезет через туннель?
Если первое - то маршрутизация на сервере, если второе - то метрики на клиенте.
cssman: У меня не видит локальную сетку 192.168.0.* НО видит интерфейс cетевой интерфейс, который подключен к локалке. В итоге я захожу по локалке через айпи, который выдан самому серверу. Грубо говоря, захожу, на публичный айпи сервера. А потом внутри него захожу на него же через его локальный айпи и только тогда попадаю в локальную сеть.
Олег Свирчев При старте впн сервера в таблицу маршрутизации на сервере будет добавлен маршрут до сети 192.168.0.0/24 из 10.8.0.0/(маска). При подключении клиента к впн серверу ему будет отдан маршрут до сети 192.168.0.0/24.
У меня так работает.
sazhyk: К сожалению, не работает. А подсеть, которая выдается VPN клиенту отличается от локальной или та же самая? Потому что у меня она 10.8.0.0/24
Таблица роутинга выглядит как
root@vpn:~# ip route
default via 178.132.0.1 dev ens19 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
178.0.0.0/24 dev ens19 proto kernel scope link src 178.0.0.12
192.168.0.0/24 dev ens18 proto kernel scope link src 192.168.0.41
