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

PTZ-M

Винда идентифицирует соединения из тунеля (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 - ошибка в адресации?

Monya

@ptz-m в чём именно ошибка? маска сети или иное? если маска - то всё в порядке. это для примера 23 маска для 2-ух классов подряд.
П.С. извините за сумбур... увидел что неверно указал сеть в адресах - исправил

Monya

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

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

покажите пожалуйста таблицу маршрутизации

werter

Добрый.

@Monya

TLS authentication - снимаем галку

Не снимаем. Это защита от MITM.

Inter-client communication - отмечаем

Крайне не рекомендую держать один впн-сервер для всех кдиентов сразу. При компроментации сертификата сервера прийдется перегенерировать сертификаты для всех клиентов этого сервера. Или 1 сервер=1 клиент или разбить на группы.

NAT - outbound
добавляем правило

Не требуется. По умолч. NAT на опенвпн откл. Проверено на последнем 2.4.х

P.s. У меня на впн-клиенте в Custom :

persist-tun;
persist-key;
resolv-retry infinite;
remote-cert-tls server;
keepalive 5 10;

Monya

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

По умолч. NAT на опенвпн откл. Проверено на последнем 2.4.х

Всё возможно. Просто за 6 лет использования pfSense начиная с версии 2.0.1 заметил что n-ное колличество инсталяций по разному обрабатывают данный факт, несмотря на единообразную настройку онных. К сожалению на x86-only железках где обитает на данный момент 2.3.5_2 обновляемых с 2.0.1 и 2.2 это не работает без явного правила, при чём неважно натировать или нет... главное чтобы правило присутствовало.

pigbrother

Пользуюсь OpenVPN начиная с 2.0.1
Никаких правил в outbound не создавал.

По поводу назначения статических адресов клиентов. Использую альтернативный способ:

Для topology subnet. Для net30 тоже работает, но адреса нужно выдавать с иным шагом, не подряд.

создаем текстовый файл ips.list вида
user1,10.11.11.20
user2,10.11.11.21
user3,10.11.11.22
……
где
10.11.11.0/24 - сеть туннеля.
userX - common name пользователя.

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

В Advanced сервера добавляем:
ifconfig-pool-persist /var/games/ips.list 0;
(0) - ноль обязателен.
т.е. мой ips.list лежит в /var/games.
Свой положите и назовите как\где хотите.
Редактироват ips.list желательно при остановленном сервере или отсутствии подключенных пользователей.

PTZ-M

@monya

0_1530000138435_маршруты.jpg

dev 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
route 192.168.1.0 255.255.255.0 172.16.0.2

iroute 192.168.1.0 255.255.255.0
ifconfig-push 172.16.0.2 255.255.255.0

P.S. решил зайти с другого конца
почитал - http://www.irz.net/sites/default/files/documentation/Router_iRZ_C02_Tunnels_RU.pdf пункт 2.2, углубился в вопрос - https://serveradmin.ru/nastroyka-openvpn-na-centos-7/#_openvpn_8212_TAP_TUN пункт 6.1, обратился к оф. ману - https://community.openvpn.net/openvpn/wiki/305-what-is-the-difference-between-a-tun-device-and-a-tap-device
пришла мысля, что изначальный проект сменил хардварную реализацию, поэтому стоит от tap уйти к tun, поскольку tap - это мост, а tun - маршрутизация.

Monya

@ptz-m маршруты верны. Посмотрите трейс до внутреннего клиента. Перепроверьте правила файервола. Судя по таблице маршрутизации у вас может возникать только проблема с натированием при условии разрешающего правила на интерфейсе и правильном направлении трафика.

werter

Добрый.

@ptz-m said in Маршрутизация OpenVPN:
iroute 192.168.1.0 255.255.255.0; <--
ifconfig-push 172.16.0.2 255.255.255.0; <--

Важно ;

P.s. Не морочьте себе голову со статикой для впн-клиентов. Решите сперва проблему с прохождением трафика. Не хватайтесь за все сразу.

PTZ-M

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

Важно ;

С ним и прописано в конфиге, просто в самом файле интерпретируется без этих разделителей

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

Решите сперва проблему с прохождением трафика.

дык я уже который пост и бьюсь над этим

Monya

@ptz-m сделайте трасировку с клиентской машины в головной сети, при этом смотрите лог файрвола в динамике. Отладка требует учесть несколько моментов. Но честно говоря очень странно что фактически при верном конфиге у вас не идёт трафик. Попробуйте всё-таки правило NAT создать.

PTZ-M

Добавил себе гемора!
Попробовал в настройках сервера сменить tap на tun - результата не дало, а вот возврат назад дал хреновый результат - 1. теперь все подключаемые клиенты получают по умолчанию адрес 172.168.0.2, соответственно ни хрена не работает. грохгул Специфические Настройки Клиента - не помогло. 2. хоть со стороны клиентов, пинг идёт на компы в серверной сети, шару видят только на центральном сервере, на остальных хоть зашарься внутри серверной сети всё ок, а за VPN тишина

werter

Добрый.

Только заметил, что у вас там TAP. Ну и каша.

Так с ТАР маршрутизация не работает. Это ж L2.
Зачем вам ТАР вообще? В 99% исп-ся TUN.
TAP исп-ся, если необходима работа в сети с одной адресацией (широковещание). И это редкий случай.

PTZ-M

@werter изначально всё делалось под клиенты на каждый ПК, это уже полгода спустя было решено маршрутизаторы связать. настраивалось по этому ману - https://habr.com/post/312528/
другой вопрос, почему смена в настройках сервера tap на tun не принесла толку, а только грохнуло раздачу ИП для туннеля

werter

По ссылке у человека специфическая задача

— я работаю с tap туннелем, мне так удобнее, он имитирует L2 уровень. С ним работают всякие мультикасты, бродкасты и т.п.;

У вас такие же условия ? Если нет, то используйте TUN.

Типа https://www.ceos3c.com/pfsense/configure-openvpn-for-pfsense-2-3-step-by-step/, но внимательно и под себя.

PTZ-M

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

У вас такие же условия ?

почти, сейчас касса Атол в серверной сети, клиент через VPN коннектится RDP к серверу и печатает на ней. потом "на лошадях" отправляем в офис клиента чек - как понятно гемор аХренеть какой.

не говоря о том, что админить сеть приходиться через дырки в мире, что вообще не комильфо

P.S. почитал мануал - не понял своей ошибки; тут он вообще весь обрезанный, есть мануал понятней и на русском - https://1cloud.ru/help/network/nastrojka-point-to-site-vpn-s-pomoshchyu-openvpn-remote-access-server-na-pfsense А так я не стал создавать VPN User - а) у десктопного клиента постоянно вылазит окно с авторизацией, а для women - это ahtung! б) что важнее zyxel и иже с ним эту авторизацию не воспринимают априори (см. ссылки на маны выше)
Dynamic DNS Service мне вообще боком - у меня white IP v4 на WAN, можно было б заморочить его для 4G модема (правда это резерв чисто для головного офиса), но проще 2-го проводного провайдера подтянуть.
В остальном разницы не увидел, пжст ткните носом где не прав

P.S.S. грохнул сервер, мастером сделал заново, вообще по дефолту, ток дописал наши обсуждения

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
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 udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
multihome
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
duplicate-cn
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"
passtos
persist-remote-ip
float
topology subnet
route 192.168.1.0 255.255.255.0 172.16.0.2

iroute 192.168.1.0 255.255.255.0

Удалось вернуть раздачу ИП, а вот с остальным по прежнему глухо - клиенты друг друга не видят, пинги из серверной сети вместо туннеля летят к провайдеру - всё вернулось к началу...