static routes в OpenVPN вызывает поломку туннеля до ребута маршрутизатора

derwin

и со стороны сервера

push "route 172.16.129.8 255.255.255.255"

тоже ломает туннель, но ребут не требуется.

pigbrother

@derwin said in static routes в OpenVPN вызывает поломку туннеля до ребута маршрутизатора:

подсеть например 172.16.129.8/32

Может потому, что 172.16.129.8/32 - это реально не сеть, а единственный IP?

derwin

именно так. Что вас смущает? разницы нет, будь там хоть /16, хоть /29
эТо же в любом случае сеть

derwin

кстати, ещё новость.

route 172.16.129.8 255.255.255.255

Такой вариант приводит к ошибке парса конфига OpenVPN, и он не может запуститься. Весь интернет, и офф документация с таким вариантом.

Чтобы запустить указал так:

route 172.16.129.8 255.255.255.255 192.168.202.1

последний адрес - адрес в туннеле удалённой стороны. Тоже баг и бред. Буду писать в редмайн.

pigbrother

@derwin said in static routes в OpenVPN вызывает поломку туннеля до ребута маршрутизатора:

последний адрес - адрес в туннеле удалённой стороны. Тоже баг и бред. Буду писать в редмайн.

указание шлюза в push route, по крайней мере, IMHO - канонический способ.
Для pfSense этого делать не приходилось, но для клиента Open VPN Микротика push route без указания шлюза работает только для сети за pfSense, для всех других сетей указание шлюза обязательно.

derwin

никогда он не был каноничным.
http://trlj.blogspot.com/2013/08/pfsense-site-to-site-openvpn-pptp-vs.html
вот вам пример из гугла.
Вот вам каноничный пример от rubic https://forum.netgate.com/topic/53022/openvpn-psk-site-to-site-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1%8F-%D0%B4%D0%BB%D1%8F-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F (сделайте поиск по странице по слову route)
В документации тоже самое https://www.netgate.com/docs/pfsense/vpn/openvpn/troubleshooting-openvpn-internal-routing-iroute.html
Самое главное, по этой же причине не работает секция remote networks в настройках туннеля. Параметры в ней не парсятся и игнорятся

werter

Добрый.
@derwin said in static routes в OpenVPN вызывает поломку туннеля до ребута маршрутизатора:

никогда он не был каноничным.
http://trlj.blogspot.com/2013/08/pfsense-site-to-site-openvpn-pptp-vs.html

По ссылке :

Routing of additional networks (we can only define one local subnet in openVPN default configuration), add "route 172.16.1.0 255.255.255.0" in advanced configuration box. Of course, the router(pfsense) protecting that network must know how to reach it(add static route)

Ни слова о явном указании адреса туннеля в директиве route ...

В документации тоже самое https://www.netgate.com/docs/pfsense/vpn/openvpn/troubleshooting-openvpn-internal-routing-iroute.html

По ссылке все же речь о директиве iroute, к-ая дает возможность "видеть" сеть за клиентом. Да, там указано, что :

On the server side, every iroute needs a corresponding route. The route entries are for the OS to know that the subnet(s) should be routed to OpenVPN from at the OS level. The iroute statements are internal to OpenVPN, so it knows which network goes to which client based on its certificate.

И снова ни слова о том, что надо явно указывать адрес туннеля.

derwin

@werter said in static routes в OpenVPN вызывает поломку туннеля до ребута маршрутизатора:

route

о том и речь. Что нигде в документации явный шлюз не фигурирует.
iroute тоже не даёт запускаться туннелю.

werter

@derwin
По какой схеме построен туннель?
В случае сервер-клиент на сертификатах все должно работать. Когда же p2p - тут не готов ответить, т.к. ее не пользую.

нигде в документации явный шлюз не фигурирует.

Где-то попадалось, когда весь трафик заворачивался в туннель, но локальный должен был ходить через локальный шлюз.
Вот тогда была применена схема route x.x.x.x y.y.y.y z.z.z.z; , где z.z.z.z - адрес локального шлюза.

P.s .Статья о настройке опенвпн между пф и микротиком - https://forums.openvpn.net/viewtopic.php?t=21221

P.p.s. Есть мануал от мая 2017 года. Раздается по офиц. подписке. Многое объяснено оч. хорошо. Кому нужно, тот найдет )

derwin

p2p
я 7 лет так работал, и теперь вижу что "как обычно" не работает. Это баг, и решение с запуском туннеля через указание шлюза я нашёл в англ ветке. Топик от марта 2018г.