Маршрутизация OpenVPN

PTZ-M

Ох как туго мозг включается после отпуска, да ещё и интерфейс форума переделали...

@pigbrother
Насколько помню iroute в OpenVPN давным давно "грохнули" как атавизм, и без него норм работает на новых версиях.
LAN правило - м-м, оно вместо статического маршрута работает?

P.S. ещё вроде как tap на TCP надо переходить, а то с MultiWAN будут проблемы при UDP

P.S.S. кста, в видео, что выше, чувак делает точка-точка, а у меня точка-многоточка!

pigbrother

@ptz-m said in Маршрутизация OpenVPN:

Насколько помню iroute в OpenVPN давным давно “грохнули” как атавизм, и без него норм работает на новых версиях.

Нет, это не так.
route говорит серверу - у тебя есть маршрут в a.b.с.d/24
iroute говорит серверу, что сеть a.b.с.d/24 находится за конкретным клиентом.

@ptz-m said in Маршрутизация OpenVPN:

LAN правило - м-м, оно вместо статического маршрута работает?

Нет, в pfSense иногда проявляется особенность, заставлюющая это правило создавать (если интересно - гуглите ветку на предмет negate rules)

@ptz-m said in Маршрутизация OpenVPN:

P.S. ещё вроде как tap на TCP надо переходить, а то с MultiWAN будут проблемы при UDP

Про это не слышал

werter

@ptz-m said in Маршрутизация OpenVPN:

P.S. ещё вроде как tap на TCP надо переходить, а то с MultiWAN будут проблемы при UDP

Ерунда какая.
Не вводите др. участников в заблуждение.

P.s. Навскидку, TAP исп-ся, если необходим широковещательный домен - единая сеть с единой адресацией в ней.
В ютубе есть офиц. канал Netgate. Рекомендую видео по OpenVPN (и не только) там. Оч. доходчиво снято.

PTZ-M

@pigbrother said in Маршрутизация OpenVPN:

Про это не слышал

Да суть в технологии TCP/UDP, если VPN не ответственный (не касса или канал банка) то и х с ним. В противном случае где-то тут писалось, что тупить начинает - не понимает, что канал лёг и держит сессию. Реально может стать проблемой, если настроено кол-во подключений - слоты забиваются и до свидос.

pigbrother

@ptz-m , Использую и TCP и UDP. Никакой разницы в моем случае не замечаю.

PTZ-M

Вчера провёл эксперимент.
VPN - OpenVPN - Серверы - Локальные сети IPv4 кроме серверной сети 0.0 дописал клиентские 1.0 и т.д. В результате клиент перестал пинговать серверную сеть и открывать шару. Снёс изменения - пинг с клиента в серверную сеть снова пошёл, в обратку - по прежнему нет.
VPN - OpenVPN - Серверы - Специфические Настройки Клиента - Настройки Клиента - Расширенные добавил запись, с Обычное Имя (CN) соответствующие имени клиента VPN на сети 1.0, вида push "route 192.168.1.0 255.255.255.0". Толку 0%.
Межсетевой экран - Правила - LAN добавил запись Протокол IPv4 *, Источник LAN net, Порт *, Назначение 192.168.1.0, Порт *, Шлюз * и стало интереснее, согласно tracert пакеты в данном случае ходят по маршруту комп-pfsense-провайдер-заглушка. Убираем правило и маршрут меняется на комп-провайдер-заглушка. Тут возможно срабатывают правила, с которыми я воевал ранее - https://forum.netgate.com/topic/128281/multiwan-dns-do-not-override/19
Мысль вернулась к тому, что PfSense не пускает клиентам, поскольку просто не объявлен маршрут. Теперь вопрос - а как его прописать правильно? В Система - Маршрутизация - Статические Маршруты какая-то белиберда добавляется, предположу что надо в Межсетевой экран - Правила - OpenVPN добавить запись вида Протокол IPv4 *, Источник LAN net, Порт *, Назначение 192.168.1.0, Порт *, Шлюз *?

pigbrother

А с каким IP виден ПК, подключивщийся из сети за Zyxel к ресурсу в сети за pfSense? Обычно это видно в логах почтовых, веб и т.д серверов.

werter

Добрый.

VPN - OpenVPN - Серверы - Специфические Настройки Клиента - Настройки Клиента - Расширенные добавил запись, с Обычное Имя (CN) соответствующие имени клиента VPN на сети 1.0, вида push “route 192.168.1.0 255.255.255.0”. Толку 0%.

Enter the X.509 common name for the client certificate, or the username for VPNs utilizing password authentication. This match is case sensitive.

Т.е., если у вас впн на сертификатах + юзер и пасс - пишется имя пол-ля.
При этом пол-лю должен быть создан личный сертификат.

Если только на сертификатах - правильное CN сертфиката пол-ля.
Внимательно с этим.

PTZ-M

@pigbrother а вот это хороший вопрос... народ пользуется шарой, на pfsense в логах разве что смотреть...

@werter said in Маршрутизация OpenVPN:

Если только на сертификатах - правильное CN сертфиката пол-ля.
Внимательно с этим.

имя полностью писал -> ля-ля-ля.домен , специально 2 раза проверил

pigbrother

@ptz-m said in Маршрутизация OpenVPN:

а вот это хороший вопрос… народ пользуется шарой, на pfsense в логах разве что смотреть…

Смотреть можно на ПК с шарой. netstat, хотите в GUI -
https://live.sysinternals.com/Tcpview.exe

@ptz-m said in Маршрутизация OpenVPN:

имя полностью писал -> ля-ля-ля.домен , специально 2 раза проверил

ля-ля-ля.домен? Имеется в виду CN (common name) сертификата пользователя.

PTZ-M

@pigbrother
я уже глянул в ту сторону, на следующей неделе займусь этим вопросом

ну CN у меня есть и трёхсоставные - ля-ля-ля.город.отдел

werter

Покажите скрин того, что вы считаете CN. Так нам всем понятнее будет.

PTZ-M

@werter

не знаю что это даст, но вот - смотрите. берём имя из сертификата.
проблема то в маршрутизации на данный момент, идея с правилом в разделе OpenVPN ничего не дала. согласно tracert - по прежнему сыпет pf пакетами для 1.0 сети в мир вместо того что-бы гнать его в туннель. идея с правилом в LAN от pigbrother даёт хоть что-то, но опять же, трафик сыпется в дефолтный гейтвей и выкидываться в мир вместо туннеля. бредовая идея с созданием прослойки в виде "левого" гейтвея и прогоном трафика из LAN через него в failover выглядит диким костылём

pigbrother

Повторю свой вопрос :

@pigbrother said in Маршрутизация OpenVPN:

с каким IP виден ПК, подключивщийся из сети за Zyxel к ресурсу в сети за pfSense?

Попробуйте создать пользователя с CN попроще, из 1 слова без точек и спецсимволов.

werter

Добрый.
Адресация в сетях за сервером и клиентом какая ? Должна быть разной.

PTZ-M

@pigbrother

Винда идентифицирует соединения из тунеля (172.) и локалку серверную (0.0).
Вообще проще через Диагностика - Редактировать файл привести конфиг сервака на данный момент из /var/etc/openvpn/server1.conf

codedev ovpns1
verb 1
dev-type tap
dev-node /dev/tap1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local XXX.XXX.XXX.XXX
tls-server
server 172.16.0.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server.ля-ля-ля.mainframe' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 192.168.0.0 255.255.255.0"
client-to-client
ca /var/etc/openvpn/server1.ca 
cert /var/etc/openvpn/server1.cert 
key /var/etc/openvpn/server1.key 
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
ncp-ciphers AES-256-GCM:AES-128-GCM
comp-lzo adaptive
push "comp-lzo adaptive"
persist-remote-ip
float

P.S. глянул в ман - http://www.lissyara.su/doc/man/safety/openvpn/ , слазил client-config-dir - я так понимаю тут и лежат активные VPN - OpenVPN - Специфические Настройки Клиента - CSC специфические настройки. Вот ток не все, а только из раздела Расширенные

P.S.S. вот сразу надо было в норм конфиг OpenVPN залезть! Появилась мысль вида:
VPN - OpenVPN - Специфические Настройки Клиента - CSC специфические настройки - Расширенные нужно правильный синтаксис писать iroute 192.168.1.0 255.255.255.0
VPN - OpenVPN - Серверы - Расширенные настройки - Особые параметры прописать route 192.168.1.0 255.255.255.0
А я как дурак пишу push "route 192.168.10.0 255.255.255.0" и т.д. из хелпа PfSense.

@werter
разуметься разная, в противном случае начинает глючить сеть со стороны клиента

pigbrother

@ptz-m said in Маршрутизация OpenVPN:

Винда идентифицирует соединения из тунеля (172.

А должна из сети за клиентом.

@ptz-m said in Маршрутизация OpenVPN:

нужно правильный синтаксис писать iroute 192.168.1.0 255.255.255.0

Отмтайте тему назад и посчитайте, сколько раз про iroute вам тут говорили.

Момент номер 2.
Убедитесь что Zyxel не поднимает NAT для своего OpenVPN интерфейса.

@ptz-m said in Маршрутизация OpenVPN:

Вообще проще через Диагностика - Редактировать файл привести конфиг сервака на данный момент из /var/etc/openvpn/server1.conf

Нет. Этого делать не надо. Если и сработает - до до первой перезагрузки. Плюс pfSense - практически идеал в смысле GUI настроек вообще, OpenVPN - в частности.
Более того, даже для iroute есть GUI-аналог, да еще хорошо откомментированный:
IPv4 Remote Network/s
These are the IPv4 networks that will be routed to this client specifically using iroute, so that a site-to-site VPN can be established. Expressed as a comma-separated list of one or more CIDR ranges. May be left blank if there are no client-side networks to be routed.
NOTE: Remember to add these subnets to the IPv4 Remote Networks list on the corresponding OpenVPN server settings.
В pfSense можно настроить OpenVPN практическти не используя поля Advanced.

PTZ-M

@pigbrother
какая-то каша пошла в теме...

редактируемый файл слететь не должен, это не MyPBX с астериском в виртуалке
причём тут route и iroute? я просто в первоначальном варианте писал с "..." (чего делать не надо было), а когда переписал на верный синтаксис, у меня клиенты по прежнему сервер шары видят, а сервер их не видит, если с него их пинговать! и трейс с сервака я приводил не для красоты - пакеты улетают в WAN вместо OpenVPN туннеля.
а как Zyxel с NDIS, NAT может поднять на OpenVPN? У него ISP вообще основной, а всё остальное или туннелируется через него(IPPoE, VPN) или идёт параллелкой (VLAN). или мысль была, что он делает masqueradin на OpenVPN? ну дак по скрину и видно, что он это делает, причём по умолчанию. никаких настроек там нет - https://help.keenetic.com/hc/ru/articles/115005717009-%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0-OpenVPN , даже сервер настраиваться без особого конфигурирования - https://help.keenetic.com/hc/ru/articles/115005822629-OpenVPN-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80-%D0%BD%D0%B0-Keenetic
а вот с чего это вдруг? ладно Zyxel имеет DHCP на том конце 172.16.0.2, а на 172.16.0.3 у меня просто комп висит, он-то ИП должен откуда в TAP брать тогда? я конечно понимаю, что по логике выходит, что концы туннеля - это оконечные устройства и соответственно за ними пустота, но в чём тогда смысл конфигурирования L2 как клиентов? если получается должна быть сеть из серверов...

вообще странно то что пинг не улетает на концы туннеля из локалки серверной (пробовал с PfSens-а пускать до компа на 0.3 - пингует зараза...), вот начало пингуется 172.16.0.1, а концы 0.2 и 0.3 - нет..

Monya

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

1 этап - настройка сервера

Server mode - Remote Access
Protocol - UDP (меньше накладных расходов)
Device mode - tun
Local port - 1194 (по умолчанию) можете изменить на свой
TLS authentication - снимаем галку
IPv4 Tunnel Network - ваша туннельная сеть (10.0.1.0/24)
IPv4 Local network(s) - головная локальная сеть офиса А (192.168.72.0/24)
Compression - открыто с адаптивной компрессией
Inter-client communication - отмечаем
Address Pool - отмечаем
Topology - выбираем Subnet
Disable IPv6 - если у вас в сети нет IPv6 - отмечаем
Custom options пишем следующее:

keepalive 10 60;
persist-key;
persist-tun;

route 192.168.166.0 255.255.255.0 10.0.1.166;
route 192.168.9.0 255.255.254.0 10.0.1.9;

Это добавит в таблицу роутера маршруты в клиентские сети

2 этап - клиентские параметры на стороне сервера
В разделе Client Specific Overrides создаём конфиги клиентов

CN - обязательно должен соответствовать CN (Common Name) указанному в сертификате
в поле Advanced пишем:

ifconfig-push 10.0.1.166 255.255.255.0;

Тем самым назначая адрес клиенту. Выше мы объявили маршрут через этот адрес

3 этап - правила firewall и NAT на стороне сервера
Firewall

на интерфейсе WAN (внешний, может отличаться от моего имени)
Action - pass
Protocol - UDP
Source - any
Destination - WAN address
Destination Port Range - 1194 (или тот который указывали в сервере)

данным правилом разрешаем внешние подключения к сервису OpenVPN

на интерфейсе OpenVPN создаём разрешающее правило any - any - any (протокол - откуда - куда)
регулировать потом будете при необходимости

NAT - outbound
добавляем правило
Do not NAT - отмечаем, тем самым снимаем натирование, ведь мы сделали маршрутизацию (если будут проблемы с прохождением пакетов, можете включить)
Interface - OpenVPN (общий псевдоинтерфейс)
Source - any
Destination - any

4 этап - клиент

настройка клиента минимум - советую лишь добавить Custom options

keepalive 10 120;
persist-key;
persist-tun;

повторяем правила NAT и Firewall для интерфейса OpenVPN

Если захотите извращенств типа L2 (единая сеть для всех филиалов) средствами OpenVPN могу так-же написать инструкцию, но прежде стоит подумать много раз о зависимостях и последствиях такого решения в случае выхода из строя сервиса OpenVPN

PTZ-M

@monya said in Маршрутизация OpenVPN:

L2 (единая сеть для всех филиалов) средствами OpenVPN могу так-же написать инструкцию

буду благодарен, пока что NAT - outbound мне не помог загнать трафик из серверной сети в туннель(

в 1 этапе пункт 13 - ошибка в адресации?