Маршрутизация OpenVPN
-
Добрый.
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 сертфиката пол-ля.
Внимательно с этим. -
@pigbrother а вот это хороший вопрос... народ пользуется шарой, на pfsense в логах разве что смотреть...
@werter said in Маршрутизация OpenVPN:
Если только на сертификатах - правильное CN сертфиката пол-ля.
Внимательно с этим.имя полностью писал -> ля-ля-ля.домен , специально 2 раза проверил
-
@ptz-m said in Маршрутизация OpenVPN:
а вот это хороший вопрос… народ пользуется шарой, на pfsense в логах разве что смотреть…
Смотреть можно на ПК с шарой. netstat, хотите в GUI -
https://live.sysinternals.com/Tcpview.exe@ptz-m said in Маршрутизация OpenVPN:
имя полностью писал -> ля-ля-ля.домен , специально 2 раза проверил
ля-ля-ля.домен? Имеется в виду CN (common name) сертификата пользователя.
-
@pigbrother
я уже глянул в ту сторону, на следующей неделе займусь этим вопросомну CN у меня есть и трёхсоставные - ля-ля-ля.город.отдел
-
Покажите скрин того, что вы считаете CN. Так нам всем понятнее будет.
-
не знаю что это даст, но вот - смотрите. берём имя из сертификата.
проблема то в маршрутизации на данный момент, идея с правилом в разделе OpenVPN ничего не дала. согласно tracert - по прежнему сыпет pf пакетами для 1.0 сети в мир вместо того что-бы гнать его в туннель. идея с правилом в LAN от pigbrother даёт хоть что-то, но опять же, трафик сыпется в дефолтный гейтвей и выкидываться в мир вместо туннеля. бредовая идея с созданием прослойки в виде "левого" гейтвея и прогоном трафика из LAN через него в failover выглядит диким костылём -
- Повторю свой вопрос :
@pigbrother said in Маршрутизация OpenVPN:
с каким IP виден ПК, подключивщийся из сети за Zyxel к ресурсу в сети за pfSense?
- Попробуйте создать пользователя с CN попроще, из 1 слова без точек и спецсимволов.
-
Добрый.
Адресация в сетях за сервером и клиентом какая ? Должна быть разной. -
Винда идентифицирует соединения из тунеля (172.) и локалку серверную (0.0).
Вообще проще через Диагностика - Редактировать файл привести конфиг сервака на данный момент из /var/etc/openvpn/server1.confcodedev 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
разуметься разная, в противном случае начинает глючить сеть со стороны клиента -
@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. -
@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 - нет..
-
Доброго времени суток.
надеюсь ещё в силе ваш зов о помощи. даю инструкцию как это реализовано у меня на одной из филиальных сетей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 - any4 этап - клиент
- настройка клиента минимум - советую лишь добавить Custom options
keepalive 10 120; persist-key; persist-tun;
- повторяем правила NAT и Firewall для интерфейса OpenVPN
Если захотите извращенств типа L2 (единая сеть для всех филиалов) средствами OpenVPN могу так-же написать инструкцию, но прежде стоит подумать много раз о зависимостях и последствиях такого решения в случае выхода из строя сервиса OpenVPN
-
@monya said in Маршрутизация OpenVPN:
L2 (единая сеть для всех филиалов) средствами OpenVPN могу так-же написать инструкцию
буду благодарен, пока что NAT - outbound мне не помог загнать трафик из серверной сети в туннель(
в 1 этапе пункт 13 - ошибка в адресации?
-
@ptz-m в чём именно ошибка? маска сети или иное? если маска - то всё в порядке. это для примера 23 маска для 2-ух классов подряд.
П.С. извините за сумбур... увидел что неверно указал сеть в адресах - исправил -
@ptz-m said in Маршрутизация OpenVPN:
пока что NAT - outbound мне не помог загнать трафик из серверной сети в туннель
покажите пожалуйста таблицу маршрутизации
-
Добрый.
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; -
@werter said in Маршрутизация OpenVPN:
По умолч. NAT на опенвпн откл. Проверено на последнем 2.4.х
Всё возможно. Просто за 6 лет использования pfSense начиная с версии 2.0.1 заметил что n-ное колличество инсталяций по разному обрабатывают данный факт, несмотря на единообразную настройку онных. К сожалению на x86-only железках где обитает на данный момент 2.3.5_2 обновляемых с 2.0.1 и 2.2 это не работает без явного правила, при чём неважно натировать или нет... главное чтобы правило присутствовало.
-
Пользуюсь 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 желательно при остановленном сервере или отсутствии подключенных пользователей. -
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 - маршрутизация. -
@ptz-m маршруты верны. Посмотрите трейс до внутреннего клиента. Перепроверьте правила файервола. Судя по таблице маршрутизации у вас может возникать только проблема с натированием при условии разрешающего правила на интерфейсе и правильном направлении трафика.