OpenVPN PSK: Site-to-Site инструкция для обсуждения

pigbrother

@deadlymic said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

Конечно же, правила.

Выходит - эти правила все же нужны, хотя необходимость в них неявная, в свое время это обсуждалось для pf 2.0-2.1.
Я предпочитаю в Source указывать LAN net а не any (*). Мы же говорим о правиле на LAN?

werter

Добрый.
@pigbrother said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

@deadlymic said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

Конечно же, правила.

Выходит - эти правила все же нужны, хотя необходимость в них неявная, в свое время это обсуждалось для pf 2.0-2.1.
Я предпочитаю в Source указывать LAN net а не any (*). Мы же говорим о правиле на LAN?

В зависимости от того, как они "написаны" на ЛАН. А именно - порядок их следования.
Если самым верхним будет allow any to any - тогда не нужно. Если же первее будет правило с явным указанием WAN GW, то нужно.

По этому я и прошу первым делом таблицу марш-ции и скрины правил fw от вопрошающих.

DeadlyMIC

@werter said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

Если же первее будет правило с явным указанием WAN GW, то нужно.

В моем случае, в одной из подсетей, а именно в 102, вообще нет правила с явным указанием WAN GW, просто дефолт и все. Но без дополнительного правила именно для 101 102 локалка в 101 не шла.

MythOfTheLight

есть проблемка - сделал по инструкции - всё замечательно работает:

Головное здание - поднял 3 сервера, к нему успешно подключилось 3 филиала. Пинги из головного ходят на все компьютеры филиалов, а вот с филиалов - только в "голову".

В статье есть на это дополнение:
"После поднятия туннеля компьютеры филиала 2 пингуют компьютеры головного офиса и наоборот, но нет связи между филиалами. Для того, чтобы филиалы “видели” друг-друга, необходимо в настройках клиента первого филиала в Advanced Configuration вписать директиву:

route 192.168.30.0 255.255.255.0

т. е. маршрут через туннель в сеть второго филиала. А в настройках клиента второго филиала, соответственно:

route 192.168.20.0 255.255.255.0

т. е. маршрут в сеть первого филиала."

Я так понимаю, в поле адвансед пишем - push "route 192.168.20.0 255.255.255.0" в второй филиал и аналогично делаем 1му филиалу. В таблице Routes добавляется запись, что ходить туда-то через сюда-то, НО пинги всё-равно не идут. Firewall тушил полностью, чтоб не влиял на замеры - всё-равно между филиалами пингов не ходит

pigbrother

@MythOfTheLight Напишите маршруты непосредственно на клиентах. Плохо помню, на в PSK их передача с сервера через push не работает.

И пока не поздно, рассмотрите переход с PSK на PKI,
Один сервер на все филиалы, (при желании - и для удаленных клиентов), проще настраивать маршрутизацию, прочие преимущества.
https://forum.netgate.com/topic/53251/openvpn-pki-site-to-site-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1%8F-%D0%B4%D0%BB%D1%8F-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F?page=1

MythOfTheLight

@pigbrother маршруты прописаны именно на клиентах, в Routes они отображаются маршрут такой то через gateway 10.0.8.1 ovpnc1

Но пинги не идут =(

PKI это через сертификаты, но суть не меняется же? У меня к 1 серверу подключался только 1 клиент Site to Site PKI остальные не могли, отрубал первый - подключался второй или третий, кто успеет. При этом, топологию менял на net30 и subnet - всё равно один клиент... Сначала использовал x86 2.3.5, сейчас все машины перевёл на x64 2.4.4 - ситуация не меняется... пока настроил кучу пар сервер-клиент между всеми зданиями, но это ведь колхоз

Konstanti

@MythOfTheLight Здр
Проблем возможных я вижу тут две

Это неверно настроены маршруты
Пакеты блокирует файрвол.

Чтобы диагностировать проблему , используйте tcpdump в разных контрольных точках
Включаете бесконечный ping на удаленном клиенте А в сторону удаленного клиента Б
1 контрольная точка
openvpn интерфейс PFsense клиента А
2 контрольная точка
openvpn интерфейс PFSense Центрального офиса в сторону клиента Б
3 контрольная точка
openvpn интерфейс PFsense клиента Б

А дальше уже анализируете ,где идет потеря пакетов (на каком этапе)
tcpdump -nettti имя_openvpn_интерфейса icmp and host ip_адрес_клиента_Б

При настройке доступа по PKI сколько сертификатов клиентов использовалось ?

MythOfTheLight

@Konstanti каждому клиенту выдавался свой сертификат, с таких же сертификатов без проблем подключил три мобильных телефона к серверу режиме Remote Access. При этом телефоны так же не пингуют филиалы, только головное здание. Завтра на месте буду искать где теряются пакеты по инструкции.

Странное поведение в том, что делаю всё по инструкциям, найденным на разных источниках, во всех случаях инструкции одинаковые, и ВПН заводится без проблем, кроме того - что филиалы не видят друг-друга

З.Ы. - пробовал добавлять правила разрешающее весь трафик на любые порты tcp/udp на всех интерфейсах всех роутеров (wan, lan, ovpn) - всё-равно пакеты не ходят, думаю проблема не в файрволе а в кривых маршрутах...

MythOfTheLight

@Konstanti

@pigbrother said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

@MythOfTheLight Напишите маршруты непосредственно на клиентах. Плохо помню, на в PSK их передача с сервера через push не работает.

И пока не поздно, рассмотрите переход с PSK на PKI,
Один сервер на все филиалы, (при желании - и для удаленных клиентов), проще настраивать маршрутизацию, прочие преимущества.
https://forum.netgate.com/topic/53251/openvpn-pki-site-to-site-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1%8F-%D0%B4%D0%BB%D1%8F-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F?page=1

Уррааааа, не знаю каким чудом, но пакеты начали ходить!
Перенастроил ночью (пока организация не работала) всю структуру VPN с помощью Perr to Peer PKI, внимательно перечитав вышеприведённую инструкцию, создал новый CA, на этой же машине поднял сервер, на этой же машине выдал всем сертификаты и импортировал на клиентов.

Особенностью хождения пакетов оказалась необходимость:

Серверу заполнить IPv4 Remote network(s) - все сети, находящиеся у клиентов.
Серверу заполнить iroute 192.168.x.0/24 255.255.255.0 в поле Advanced в секции Client Specific Overrides - для каждой сети, находящейся у клиентов, указав уникальное имя сертификата
Каждому клиенту заполнить поле IPv4 Remote network(s) - указав сеть сервера, и всех его клиентов.
на Firewall открыть порт UDP 1194 на WAN для связи с сервером/клиентами (ну или любой другой на котором поднят сервер) и главное - открыть в Firewall на интерфейсе OpenVPN - any to any на всех портах

У меня в моём случае был поочередно пропущен либо 1 либо 2 либо 3 пункт, из за невнимательности.

З.Ы. - ещё почему-то пакеты не ходят когда сервер и клиент разной версии и битности - сервер поднят на х64 2.4.4, все клиенты тоже, но один клиент х86 2.3.5-2 - соединение поднимается, IP 10.10.10.5 присваивается - но ни сервер не пингует клиент, ни клиент сервер. на остальных 7 машинах 2.4.4 работает.
Выходит если версии различаются, досвидос? Старый комп работает уже 3й год с pfSense х86 версии, проц х64 не поддерживает (( придётся менять похоже.

pigbrother

@MythOfTheLight said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

ни клиент сервер. на остальных 7 машинах 2.4.4 работает.
Выходит если версии различаются, досвидос? Старый комп работает уже 3й год с pfSense х86 версии, проц х64 не поддерживает (( придётся менять похоже.

Разрядность клиента не важна. Запустите клиента от имени администратора.

werter

Добрый
@MythOfTheLight

З.Ы. - ещё почему-то пакеты не ходят когда сервер и клиент разной версии и битности - сервер поднят на х64 2.4.4, все клиенты тоже, но один клиент х86 2.3.5-2 - соединение поднимается, IP 10.10.10.5 присваивается - но ни сервер не пингует клиент, ни клиент сервер. на остальных 7 машинах 2.4.4 работает.
Выходит если версии различаются, досвидос? Старый комп работает уже 3й год с pfSense х86 версии, проц х64 не поддерживает (( придётся менять похоже.

Тип сети для ВПН на net30 на сервере смените. Старые клиенты не умеют тип Subnet.

pigbrother

@werter said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

Тип сети для ВПН на net30 на сервере смените. Старые клиенты не умеют тип Subnet.

ХР SP3 работает с Subnet. У меня еще есть такие клиенты. Win2000 - наверное нет, проверить не на чем.

MythOfTheLight

@pigbrother клиент - это pfSense 2.3.5 x86, где там запуск от имени администратора =))

@werter вся сеть поднята на subnet - т.к. сервер - pfSense 2.4.4 x64 и клиенты 2.4.4 x64, кроме одного - 2.3.5 x86

Компьютеры в сети даже не знают что они в VPN сидят....

pigbrother

@MythOfTheLight said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

клиенты 2.4.4 x64, кроме одного - 2.3.5 x86

Чудеса. У меня зоопарк Андроидов, Микротиков, айфонов, роутеров работает с subnet. Крайне маловероятно, что дело в разрядности клиента PF. Проверьте настройки еще раз.

В старых версиях PF ингода требовалось на сервере на LAN создать неочевидное правило повыше вида
IPv4 * LAN net * 10.x.x.x/24 * * none

10.x.x.x/24 - сеть за клиентом PF.

Но вряд ли это ваш случай.

werter

Добрый.

@pigbrother said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

В старых версиях PF ингода требовалось на сервере на LAN создать неочевидное правило повыше вида

Это "неочевидное" правило и сейчас более чем очевидно в случае, если на сервере неск-ко ВАНов и нужно дать доступ и в сети впн-клиентов и выпустить через Failover_GW_Group в Инет.

pigbrother

@werter said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

Это "неочевидное" правило и сейчас более чем очевидно в случае, если на сервере неск-ко ВАНов и нужно дать доступ и в сети впн-клиентов и выпустить через Failover_GW_Group в Инет.

У меня без него не работал Open VPPN и без Failover_GW_Group.
Странно, что оно не упоминается практически ни в одном мануале.

MythOfTheLight

@pigbrother said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

@MythOfTheLight said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

клиенты 2.4.4 x64, кроме одного - 2.3.5 x86

Чудеса. У меня зоопарк Андроидов, Микротиков, айфонов, роутеров работает с subnet. Крайне маловероятно, что дело в разрядности клиента PF. Проверьте настройки еще раз.

В старых версиях PF ингода требовалось на сервере на LAN создать неочевидное правило повыше вида
IPv4 * LAN net * 10.x.x.x/24 * * none

10.x.x.x/24 - сеть за клиентом PF.

Но вряд ли это ваш случай.

Сделал несколько повторных тестов двух машин с 2.3.5 х86 - пакеты не ходят, перекинул жесткие диски в новые компы - пинги не ходят. Обновил до 2.4.4 х64 с сохранением конфига - ничего не менял после установки - пинги сразу пошли во всех направлениях...

Сам удивляюсь тому, что это реально происходит.

NestorMahno

@MythOfTheLight said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

@pigbrother said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

@MythOfTheLight said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

клиенты 2.4.4 x64, кроме одного - 2.3.5 x86

Чудеса. У меня зоопарк Андроидов, Микротиков, айфонов, роутеров работает с subnet. Крайне маловероятно, что дело в разрядности клиента PF. Проверьте настройки еще раз.

В старых версиях PF ингода требовалось на сервере на LAN создать неочевидное правило повыше вида
IPv4 * LAN net * 10.x.x.x/24 * * none

10.x.x.x/24 - сеть за клиентом PF.

Но вряд ли это ваш случай.

Сделал несколько повторных тестов двух машин с 2.3.5 х86 - пакеты не ходят, перекинул жесткие диски в новые компы - пинги не ходят. Обновил до 2.4.4 х64 с сохранением конфига - ничего не менял после установки - пинги сразу пошли во всех направлениях...

Сам удивляюсь тому, что это реально происходит.

Неделю скакал с бубном вокруг настройки OpenVPN Site-to-Site в вариантах PSK и PKI. Удаленный сервер на 2.3.5-RELEASE-p2 (i386) P-III динозавре, клиенты на 2.4.5-RELEASE (amd64). В случае настройки по PSK трафик по туннелю и между клиентами ходит, в случае настройки сервера по PKI (SSL-TSL) пингуются только концы туннелей. По сто раз проверял правила файрвола, настройки маршрутизации, ну нет косяков... А оказывается надо было просто выкинуть древний третий пентиум и поставить pfsense на 64 разрядный проц... Теперь придется ждать когда перемрет коронавирус, чтобы можно было приехать заменить сервер.

pigbrother

@werter said in OpenVPN PSK: Site-to-Site инструкция для обсуждения:

Это "неочевидное" правило и сейчас более чем очевидно в случае, если на сервере неск-ко ВАНов и нужно дать доступ и в сети впн-клиентов и выпустить через Failover_GW_Group в Инет.

Да. Недавно пришлось вспомнить. Стоит задействовать группу шлюзов для выхода в интернет и без этого правила сеть за клиентом Open VPN становится недоступна.