Маршрутизация OpenVPN
-
Добрый.
Только заметил, что у вас там TAP. Ну и каша.
Так с ТАР маршрутизация не работает. Это ж L2.
Зачем вам ТАР вообще? В 99% исп-ся TUN.
TAP исп-ся, если необходима работа в сети с одной адресацией (широковещание). И это редкий случай. -
@werter изначально всё делалось под клиенты на каждый ПК, это уже полгода спустя было решено маршрутизаторы связать. настраивалось по этому ману - https://habr.com/post/312528/
другой вопрос, почему смена в настройках сервера tap на tun не принесла толку, а только грохнуло раздачу ИП для туннеля -
По ссылке у человека специфическая задача
— я работаю с tap туннелем, мне так удобнее, он имитирует L2 уровень. С ним работают всякие мультикасты, бродкасты и т.п.;
У вас такие же условия ? Если нет, то используйте TUN.
Типа https://www.ceos3c.com/pfsense/configure-openvpn-for-pfsense-2-3-step-by-step/, но внимательно и под себя.
-
@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
Удалось вернуть раздачу ИП, а вот с остальным по прежнему глухо - клиенты друг друга не видят, пинги из серверной сети вместо туннеля летят к провайдеру - всё вернулось к началу...
-
@monya said in Маршрутизация OpenVPN:
сделайте трасировку с клиентской машины в головной сети
делал, см. выше - уходит сразу в сетку провайдера. вот из под клиента до сервера
@monya said in Маршрутизация OpenVPN:
Попробуйте всё-таки правило NAT создать
какое? а то я уже утонул во всём этом мракобесье...
-
@ptz-m said in Маршрутизация OpenVPN:
делал, см. выше - уходит сразу в сетку провайдера. вот из под клиента до сервера
Я вас спрашивал - с каким IP ПК за сервером видят ПК из сети за клиентом. Насколько помню - не с IP из LAN за клиентом. Если так, предположу, что Zyxel натирует клиентскую LAN через IP OpenVPN-клиента. Если так - сети за сервером не увидеть сети за клиентом.
Если я прав и, повторюсь, ПК за сервером видят соединения с ПК из сети за клиентом с IP тоннеля (соединения с разных ПК видны с одним IP тоннеля) - дело в клиенте Zyxel. -
@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 и попробуйте после этого.
-
вот такая петрушка у меня в исходящих, смущает правила на 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 лет(