Маршрутизация OpenVPN
-
А то, что кнопка "применить" в правилах на OpenVPN не нажата - нормально?
Брандмауэры на целевых серверах отключены\настроены? -
@werter
спс за ссылки, читаю, хотя они и для старых версий уже не используемых в новых ревизиях zyxel... у меня ситуация похожая на 390 пост, но насколько вижу решения не было. в затыки на стороне zyxel не в приоритете, поскольку с виндовыми клиентами та же ерунда.@pigbrother
нормально, если её нажать магия не происходит всё равно
до них ещё не доходит даже_______________________________________________________________________________________________________________________
пинганул с рабочей станции по vpn каналу из под серверной сети (поставил на комп и указал подключиться к 192.168.0.1), клиенты на винде друг друга видят (172.16.0.х), а вот серверная сеть их нет
-
@ptz-m извините за долгое отсутствие... Во первых я просил трассировку из головной сети, где находится сам OpenVPN сервер в клиентскую. Во вторых вы не сказали что у вас клиент оказывается на Зухеле а не на pfSense, в этом случае у вас на Зухеле надо добавить правило файрвола и возможно NAT (последняя строчка) он же простой Linux.
пример правилаiptables -I INPUT -i tun1 -j ACCEPT iptables -I FORWARD -i tun1 -j ACCEPT iptables -I FORWARD -i br0 -o tun1 -j ACCEPT iptables -I FORWARD -i tun1 -o br0 -j ACCEPT iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
имена интерфейсов могут отличаться
-
@monya
спс, аналогичное чуть выше скинул werter, однако суть в том , что серверная сеть не видит и клиентов на обычных виндовых машинах. не пингует и не трессирует до них, всё что имеет адрес 192.168.1.х улетает к провайдеру по умолчанию. а вот с 172.16.0.х сложнее, пинг уходит в никуда, а трейс затыкается на самом pfsense, при этом если использовать утилиту встроенную в сам pfsense и указать интерфейс openvpn для пингования - всё ок!
от сюда и возникает логичное предположение, что 192.168.0.х (серверная сеть), т.е. LAN, не имеет маршрута к OpenVPN серверу (сеть OpenVPN как бы изолированна и является внешним интерфейсом подчиняющимся NAT pfsense, что есть м бред), а как его добавить - я хз. -
@ptz-m к сожалению pfSense имеет странное явление не пропускать трафик если он не натируется как я и писал. Сделайте правило NAT - outbound и попробуйте после этого.
-
вот такая петрушка у меня в исходящих, смущает правила на WAN для 172.16.0.х
-
@ptz-m сгенерировано верно. А по поводу правила для OpenVPN, если трафик не идёт в клиентскую сеть, значит надо заменить NO NAT на адрес интерфейса. Но обычно такое я делаю только на стороне клиента а не сервера. И только когда сеть не маршрутизированная.
-
-
Добрый.
Уберите правило NAT для опенвпн. По-умолч. NAT для опенвпн выкл. Проверено.
Скорее всего у вас проблемы на Зюхеле - правила NAT, правила fw. -
@derwin
какая именно статья, и что устарело?@werter
да забудьте о бедном zyxel-е! я и под виндовыми клиентами наблюдаю полную ересь со стороны pFsense!Вот, тут тишина со стороны серверной сети за pfsense!
А вот тут всё красиво со стороны виндовых клиентов!
Вывод - openvpn, тут вообще не при делах.
-
Грохните все. И с нуля. На ЮТ есть оф. мануалы. Не спеша. Кучу времени угробили. Там делов на 15 минут.
-
@werter
если бы всё было просто, то я бы не мудыхался с этим глючущим гавном, а поставил бы CentOS ещё год назад и по нормальному всё скоммутировал через iptables.
и да, такая проблема не у меня одного, вот колхозрешение - https://forum.netgate.com/topic/44019/iptables-to-pfsense-command-line вот ток nat.conf похоже переместили за 6 лет( -
если бы всё было просто, то я бы не мудыхался с этим глючущим гавном,
Работаю с пф почти 10 лет (и еще с его папы моноволла интересовался).
Более 2-ух десятков крупных инсталляций (мелкие не в счет) Проблем особых нет. Дело 99,9 % в настраивающем.а поставил бы CentOS ещё год назад
Что мешает?
Пересмотрел ваш пост с самого начала.
Уверен, что проблема не в пф. Посмотрите, остались ли у вас маршруты на пф, добавленные руками. Если есть - удаляйте.Грохните все. И с нуля. На ЮТ есть оф. мануалы. Не спеша. Кучу времени угробили. Там делов на 15 минут.
И перезагружайте пф.
P.s. Найдите человека, к-ый вам настроит. За деньги, ес-но.
-
использую pfsense около 8 лет, нерешаемых проблем не встречал.
8 крупных инсталляций на 1000+ вланов, несколько десятков мелких.
Проблема в качестве настройщика. -
Присоединюсь.
Более человечной реализации 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 не нужны. -
Р Е Ш Е Н О
____________________________________________________________________________________________________________________
Ну во-общем, благодаря помощи 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
-
@ptz-m said in Маршрутизация OpenVPN:
Почему мастер не предлагает сделать такие настройки при конфигурировании сервера - я хз.
Дело в вашей конкретной специфике. Никогда не использовал ни алиасов, ни правил outbound NAT.
А смысл объединять алиасом сеть туннеля(?) с LAN - мне вообще непонятен. -
@pigbrother там пришлось отдельное правило писать по причине использования gateway-group в правиле для всех в качестве гетвея
П.С. получилось как-то сумбурно, но кто в теме тот поймёт -
@monya, да, любопытная конструкция получилась.
Всегда стараюсь использовать маршрутизацию, если это возможно, вместо NAT. -
Добрый.
А в чем причина использования gw group? Для чего он нужен в данном случае? Можно ли схему ? Потому как @PTZ-M об этом не упоминал.
P.s. Повторюсь. В версии 2.4.х NAT автоматом на дефолтном опенвпн-интерфейсе и так отключен. Нет надобности его явно откл.