Маршрутизация OpenVPN
-
@pigbrother я уже сервер пересоздал, но уже на TUN - маршруты pfsense в opnevpn так и не передаёт!
сейчас сижу с домашнего компа с ип 172.16.0.3 и не вижу нифига в серверной сети, кроме центрального сервера, на который в NAT настроены разные дырки. в предыдущей версии с TAP, я мог подключаться удалёнкой к своему рабочему компу.
блин такое чувство, что OpenVPN подчиняется правилам NAT pfsense! но это же бред мы для него дыру во внутрь зачем делаем! он что внешний интерфейс чтоль для LAN?!
даже добавление правила, всё равно просто задублирует основное
P.S. вот внизу интересный совет - http://bilee.com/pfsense.html пока не пробовал, а что у кого в этом разделе настроект прописано?
-
Добрый.
Впн настроен в режиме сервер-клиент или p2p ?
Выдача маршрутов 100% работает в режиме сервер-клиент.
У меня впн на сертификатах + аутентификация по связке пол-ль-пароль.
Проблем с выдачей маршрутов, "видимости" друг-друга нет. Это самый простой случай.Вот тут есть немного http://forum.zyxmon.org/topic110-openvpn-keenetic-p16.html
P.s. Настройка ipsec между Zyxell и пф http://www.nwlab.net/tutorials/VPN-pfSense-ZyWALL/. Если с опенвпн не выйдет.
-
А то, что кнопка "применить" в правилах на 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 и попробуйте после этого.
-
-
@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.0iroute 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 в правиле для всех в качестве гетвея
П.С. получилось как-то сумбурно, но кто в теме тот поймёт
