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

werter

Добрый.

Уберите правило NAT для опенвпн. По-умолч. NAT для опенвпн выкл. Проверено.
Скорее всего у вас проблемы на Зюхеле - правила NAT, правила fw.

PTZ-M

@derwin
какая именно статья, и что устарело?

@werter
да забудьте о бедном zyxel-е! я и под виндовыми клиентами наблюдаю полную ересь со стороны pFsense!

0_1530780746166_пинг.jpg

Вот, тут тишина со стороны серверной сети за pfsense!

0_1530780783939_пинг1.jpg

А вот тут всё красиво со стороны виндовых клиентов!

Вывод - openvpn, тут вообще не при делах.

werter

Грохните все. И с нуля. На ЮТ есть оф. мануалы. Не спеша. Кучу времени угробили. Там делов на 15 минут.

PTZ-M

@werter
если бы всё было просто, то я бы не мудыхался с этим глючущим гавном, а поставил бы CentOS ещё год назад и по нормальному всё скоммутировал через iptables.
и да, такая проблема не у меня одного, вот колхозрешение - https://forum.netgate.com/topic/44019/iptables-to-pfsense-command-line вот ток nat.conf похоже переместили за 6 лет(

werter

@PTZ-M

если бы всё было просто, то я бы не мудыхался с этим глючущим гавном,

Работаю с пф почти 10 лет (и еще с его папы моноволла интересовался).
Более 2-ух десятков крупных инсталляций (мелкие не в счет) Проблем особых нет. Дело 99,9 % в настраивающем.

а поставил бы CentOS ещё год назад

Что мешает?

Пересмотрел ваш пост с самого начала.
Уверен, что проблема не в пф. Посмотрите, остались ли у вас маршруты на пф, добавленные руками. Если есть - удаляйте.

Грохните все. И с нуля. На ЮТ есть оф. мануалы. Не спеша. Кучу времени угробили. Там делов на 15 минут.

И перезагружайте пф.

P.s. Найдите человека, к-ый вам настроит. За деньги, ес-но.

derwin

использую pfsense около 8 лет, нерешаемых проблем не встречал.
8 крупных инсталляций на 1000+ вланов, несколько десятков мелких.
Проблема в качестве настройщика.

pigbrother

Присоединюсь.
Более человечной реализации OpenVPN, чем в pfSense не встречал.
Одних комментариев к настройкам вполне достаточно, чтобы настроить базовую конфигурацию, плюс работающий визард. Настройки визарда легко трансформируются из Remote Access в site-to-site (peer to peer).
Реализация, IMHO, удачнее, чем в коммерческом продукте от самих разработчиков - OpenVPN Access Server
https://openvpn.net/index.php/access-server/overview
Хотите к вашим неясностям с OpenVPN добавить дзен iptables - никто не мешает. На стороне pfSense, правда, никакие манипуляции, аналогичные действиям в Линукс с iptables не нужны.

PTZ-M

Р Е Ш Е Н О

____________________________________________________________________________________________________________________

Ну во-общем, благодаря помощи Monya через удалёнку, за часа 4 - удалось победить!
Косяк явственно был в не очевидных настройках PfSense. Без помощи - вжись не допёр бы(
Делать надо по инструкции от Monya Маршрутизация OpenVPN с небольшими дополнениями из-за специфичности задачи.

Создаём маску через алиасы межсетевого экрана:
Имя - произвольное
Тип - Сеть
Сеть или имя или алиас - 192.168.1.0/24 - клиент с сетью за Zyxel
нажать +Добавить Сеть
172.16.0.0/24 - тунель vpn

Пишем правило для LAN интерфейса, ручками, поинт-энд-клик не робит)

Действие - Разрешить
Интефейс - Локальная сеть
Адресное семейство - IPv4
Протокол - Любой
Источник - Любой
Назначение - Один хост или алиас - имя алиаса берём из предыдущего шага

И не забываем правило без которого НЕ РАБОТАЕТ вся эта конструкция!

Межсетевой экран - Сетевая Трансляция Адресов - Исходящий

Не применять NAT - не стоит
Интерфейс - OpenVPN
Источник - Любой
Назначение - Любой
Адрес - Адрес Интерфейса
Порт или Диапазон - пусто
Статический Порт - не стоит
Нет синхронизации - не стоит

Остальная настройка сервера есть выше, в принципе ничего не поменялось (см. ниже). Почему мастер не предлагает сделать такие настройки при конфигурировании сервера - я хз.

Сервер:

dev ovpns1
verb 3
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
local XXX.XXX.XXX.XXX 255.255.255.0
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"
push "dhcp-option WINS 192.168.0.1"
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
topology subnet
route 192.168.1.0 255.255.255.0

route 192.168.2.0 255.255.255.0

Клиент

iroute 192.168.1.0 255.255.255.0
ifconfig-push 172.16.0.2 255.255.255.0

iroute 192.168.2.0 255.255.255.0
ifconfig-push 172.16.0.3 255.255.255.0

Из минусов - это невозможность "грохнуть" конкретное соединение, только перезагрузить весь сервис целиком = РЕШЕНО - виновата multihome, т.е. меню Протокол - UDP IPv4 and IPv6 on all interfaces ставим IPv4 и возвращается local - тогда можно гробить коннекты

В настройках Zyxel KEENETIC Extra II v12 оказалось ещё проще, правда добавил на всякий OPKG и пакет фильтрации трафика из него (хз надо ли было вообще это делать), но вроде хватает правил в файерволе через веб интерфейс - на интерфейсе OpenVPN разрешить всё для протоколов TCP, UDP, ICMP

0_1531562003989_файер.jpg

pigbrother

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

Почему мастер не предлагает сделать такие настройки при конфигурировании сервера - я хз.

Дело в вашей конкретной специфике. Никогда не использовал ни алиасов, ни правил outbound NAT.
А смысл объединять алиасом сеть туннеля(?) с LAN - мне вообще непонятен.

Monya

@pigbrother там пришлось отдельное правило писать по причине использования gateway-group в правиле для всех в качестве гетвея
П.С. получилось как-то сумбурно, но кто в теме тот поймёт

pigbrother

@monya, да, любопытная конструкция получилась.
Всегда стараюсь использовать маршрутизацию, если это возможно, вместо NAT.

werter

Добрый.

А в чем причина использования gw group? Для чего он нужен в данном случае? Можно ли схему ? Потому как @PTZ-M об этом не упоминал.

P.s. Повторюсь. В версии 2.4.х NAT автоматом на дефолтном опенвпн-интерфейсе и так отключен. Нет надобности его явно откл.

PTZ-M

@werter как это не писал?! О.о
@ptz-m said in Маршрутизация OpenVPN:

werter

Добрый.

@PTZ-M
Покажите, пож-та, где идет речь о GW GROUP (группа шлюзов). Видимо, у нас разные понятия об этом термине.

И самое главное, зачем оно в вашем случае нужно?

Desroze

И снова здравствуйте.
Вопрос появился новый, но с теми же вводными данными:
Филиал_1 PFSense 2.3.5 в качестве сервера OpenVPN
Сеть 192.168.72.0/24
Сеть OpenVPN 10.0.1.0/24
IP полученный при установлении туннеля 10.0.1.1

Филиал_2 PFSense 2.1.5 в качестве клиента
Сеть 192.168.166.0/24
Сеть OpenVPN 10.0.1.0/24
IP полученый при установлении туннеля 10.0.1.2

Надо: чтоб подсети 192.168.72.0 и 192.168.166.0 могли подружиться между собой и видеть компьютеры друг-друга.

В чем проблема:
в каждом филиале стоит по Asterisk'у, который обеспечивает внутреннюю связь. На момент создания мной данной темы не было связи между ними, но потом после настройки OpenVPN-туннеля она таки появилась, и казалось бы все хорошо.
Однако, тогда я не обратил внимания на то что пинги между астерисками, не смотря на туннель, который должен маршрутизировать все это дело, не проходят, обратил на это внимание недели через две, после того как была жалоба на отсутствие внутренней связи (казалось бы как такое возможно?).
В итоге имеем:
В целом связь между этими двумя астерисками есть, но раз-два в неделю по непонятным причинам она отваливается. При этом те же пресловутые пигни как не ходили так и не ходят. Таким же образом как отвалилась она может внезапно подняться обратно, и проработать так день-два или неделю-две. И так же без объяснения причин рухнуть.
Сегодня ситуация повторилась, в итоге дело решилось перезагрузкой PFSense который выступает в качестве сервера. Однако восстановился только SIP-канал (IAX2), если же пускать хотя бы ту же трассировку - по ней видно что она уходит до 192.168.166.1 а дальше тишина. Тем не менее если пинговать с самих PF'ов то все необходимые адреса я вижу, как со стороны OpenVPN-сервера вижу клиентский ип, так и со стороны клиента вижу астериск за сервером
Подскажите пожалуйста, в какую сторону копать?

derwin

я считаю, что впору открывать платную линию техподдержки.
Касательно Вашего случая - всё очень просто, и совсем не понятно - почему столько проблем.

Desroze

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

И снова здравствуйте.
Вопрос появился новый, но с теми же вводными данными:
Филиал_1 PFSense 2.3.5 в качестве сервера OpenVPN
Сеть 192.168.72.0/24
Сеть OpenVPN 10.0.1.0/24
IP полученный при установлении туннеля 10.0.1.1

Филиал_2 PFSense 2.1.5 в качестве клиента
Сеть 192.168.166.0/24
Сеть OpenVPN 10.0.1.0/24
IP полученый при установлении туннеля 10.0.1.2

Надо: чтоб подсети 192.168.72.0 и 192.168.166.0 могли подружиться между собой и видеть компьютеры друг-друга.

В чем проблема:
в каждом филиале стоит по Asterisk'у, который обеспечивает внутреннюю связь. На момент создания мной данной темы не было связи между ними, но потом после настройки OpenVPN-туннеля она таки появилась, и казалось бы все хорошо.
Однако, тогда я не обратил внимания на то что пинги между астерисками, не смотря на туннель, который должен маршрутизировать все это дело, не проходят, обратил на это внимание недели через две, после того как была жалоба на отсутствие внутренней связи (казалось бы как такое возможно?).
В итоге имеем:
В целом связь между этими двумя астерисками есть, но раз-два в неделю по непонятным причинам она отваливается. При этом те же пресловутые пигни как не ходили так и не ходят. Таким же образом как отвалилась она может внезапно подняться обратно, и проработать так день-два или неделю-две. И так же без объяснения причин рухнуть.
Сегодня ситуация повторилась, в итоге дело решилось перезагрузкой PFSense который выступает в качестве сервера. Однако восстановился только SIP-канал (IAX2), если же пускать хотя бы ту же трассировку - по ней видно что она уходит до 192.168.166.1 а дальше тишина. Тем не менее если пинговать с самих PF'ов то все необходимые адреса я вижу, как со стороны OpenVPN-сервера вижу клиентский ип, так и со стороны клиента вижу астериск за сервером
Подскажите пожалуйста, в какую сторону копать?

Ну так может намекнете хотя бы, если не хотите просто посоветовать? Ато от вас на протяжении топика только подколки в сторону вопрошающих и ни одного совета. И этот ваш пост про 8 инсталляций смотрятся просто как понт

derwin

у Вас каноническая задача из любого мана по настройке OpenVPN ?? чего тут обсуждать???
Для ленивых:

Лечим пинг:

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

Лечим отключения OpenVPN:

смотрим логи OpenVPN
читаем и действуем по обстоятельствам

Лечим SIP:

для начала изучаем как работает регистрация, устанавливается она по вызову или действует постоянно.
проверяем рулес на интерфейсе с SIP, чтобы там не был указан Gateway по умолчанию
смотрим логи файрвола на предмет дропов.

Как то так вобщем

derwin

ИМХО, ставить в каждый офис по астру это моветон.
Соедините всё в одну сетку, и цепляйте всех на 1 сервер.

pigbrother

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

ИМХО, ставить в каждый офис по астру это моветон.
Соедините всё в одну сетку, и цепляйте всех на 1 сервер.

И, если я правильно понимаю, в случая обрыва связи офис без своего Астерикса останется без телефонии?