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

werter

(правило "пропускать все" для OpenVPN добавлено)

Точно ВСЁ ? Потому как по-умолчанию правило только для TCP создается.

Далее ,хотелось бы увидеть таблицу маршрутизации при установленном соединение.

P.s. А проще так - включайте логирование fw и смотрите что блокируется.

mikhe

в правилах:
IPv4 * * * * * * none

маршруты на сервере:

172.19.17.0/24 172.19.19.2 UGS 0 0 1500 ovpns1
172.19.19.0/24 172.19.19.1 UGS 0 696 1500 ovpns1
172.19.19.1 link#11 UH 0 25 1500 ovpns1

И я правильно вас понял, что на пинги 172.19.19.1 при правильных настройках отзываться должен?

werter

Глупо, но со стороны сервера или со стороны клиента отзываться должен?
Далее у вас пакеты между подсетями сервера и клиента (-ов) нормально "бегают"? Если - да, то не заморачивайтесь.

P.s. А проще так - включайте логирование fw и смотрите что блокируется.

Это проверили? Смотрите логи fw - что может быть проще и нагляднее?

EternalTear

Добрый день….
Подскажите пожалуйста...
а как можно указать клиентам несколько IP адресов моего cервера?

Использовал сервис DYNDNS no-ip.org но сейчас у них проблеммы ну вот как тут можно нормально относится к Майкрософт?…. и клиенты отвалились...

как-то можно задать список IP адресов к которым клиент мог бы пытаться подключаться?... (если не доступен один то пытается подключится по другому..)

werter

Указывать несколько remote :

client

remote x.x.x.36 1194
…остальные настройки

remote x.x.x.98 1195
...остальные настройки

mikhe

@werter:

Глупо, но со стороны сервера или со стороны клиента отзываться должен?
Далее у вас пакеты между подсетями сервера и клиента (-ов) нормально "бегают"? Если - да, то не заморачивайтесь.

P.s. А проще так - включайте логирование fw и смотрите что блокируется.

Это проверили? Смотрите логи fw - что может быть проще и нагляднее?

Не пингует сам себя…Т.е. сам себя пинговать и не должен? ??? И с некоторых клиентов. Пакеты бегают в обе стороны, но не все как хотелось бы, вот хочу понять с какой стороны копать начинать. В логе тишина - те пинги что проходят есть, те что не проходят и в логе упоминаний о них нет.
Еще вопрос - в мануалах OpenVPN 2.xx в самом начале есть такие слова:
--mode m
Set OpenVPN major mode. By default, OpenVPN runs in point-to-point mode ("p2p"). OpenVPN 2.0 introduces a new mode ("server") which implements a multi-client server capability.
В конфигурационном файле, формируемом через интерфейс pfSense никаких упоминаний mode нет, т.е. работает в режиме p2p. А как сконфигурировать mode server? (В примерах и мануалах на OpenVPN тоже не нашел)

PS Немного разобрался, нужно выбирать Remote Access и директива server вставит mode server. Правда обнаружилась другая непонятная вещь - оказывается с топологией subnet формат ifconfig ip mask (как у tap)

werter

@ mikhe

В каком режиме работает у вас OpenVPN-сервер ?

mikhe

Я запускал и p2p и RA (перезагружал на всякий случай). Конфигурационные файлы различались лишь парой строк - в конфиге p2p добавлялась строка ifconfig 172.19.19.1 172.19.19.2, а в RA строка client-to-client. Разницы я не заметил - т.е. те подглюкивания, с которыми я пытаюсь бороться есть и там и там.
После внимательного чтения мана опенвпн получается что в результирующем конфиге p2p присутствуют две противоречивые строки ifconfig 172.19.19.1 172.19.19.2, которую вставлят пфсенс и ifconfig 172.19.19.1 255.255.255.0. которая генерится из server 172.19.19.0 255.255.255.0 и topology subnet

Groof

Доброе. Подскажите кто в курсе, есть ли принципиальная разница в организации маршрутизации между подключениями по схеме OpenVPN p2p (share key) и OpenVPN p2p (SSL/TSL)?

Суть проблему в том, что при настройки по схеме OpenVPN p2p (share key), трафик между двумя роутерами на базе pfsense ходит без проблем, в том числе между рабочими станциями, которые находиться в локальных сетях за этими роутерами. Если я перенастраиваю только OpenVPN для работы по схеме и OpenVPN p2p (SSL/TSL), то трафик почему получается односторонним, причем только от клиента к серверу, от сервера к клиенту трафик уже не ходит не говоря о том что и нету трафика между рабочими станциями. При этом с маршрутизации все в порядке, на клиенте есть маршрут в сеть сервера, а на сервере есть маршрут в сеть клиента. Даже если открыть полностью файрвол, то проблема останется. В чем может быть дело?

Схема следующая:
WS1(192.168.1.100)–-(192.168.1.1)pfsense1(WAN)--(WAN)pfsense2(192.168.10.1)--(192.168.10.100)WS2
Туннель в openvpn:
10.0.8.1 <-p2p-> 10.0.8.2 <=p2p=> 10.0.8.5 <-p2p-> 10.0.8.6

Таблица маршрутизации на pfsense1 192.168.1.1 (OpenVPN Server)
default 89.89.89.93 UGS 0 50332 1500 em0
10.0.8.0/24 10.0.8.2 UGS 0 3811 1500 ovpns2
10.0.8.1 link#9 UHS 0 3 16384 lo0
10.0.8.2 link#9 UH 0 0 1500 ovpns2
89.89.89.64/27 link#1 U 0 1958172 1500 em0
89.89.89.73 link#1 UHS 0 0 16384 lo0
127.0.0.1 link#6 UH 0 666 16384 lo0
192.168.1.0/24 link#2 U 0 2046000 1500 em1
192.168.1.1 link#2 UHS 0 3 16384 lo0
192.168.10.0/24 10.0.8.2 UGS 0 8093 1500 ovpns2

Таблица маршрутизации на pfsense2 192.168.10.1 (OpenVPN Client)
default 89.89.89.73 UGS 0 38973 1500 em0
10.0.8.1/32 10.0.8.5 UGS 0 1382 1500 ovpnc2
10.0.8.5 link#9 UH 0 0 1500 ovpnc2
10.0.8.6 link#9 UHS 0 4 16384 lo0
89.89.89.64/27 link#1 U 0 2051472 1500 em0
89.89.89.93 link#1 UHS 0 0 16384 lo0
127.0.0.1 link#6 UH 0 648 16384 lo0
192.168.1.0/24 10.0.8.5 UGS 0 6257 1500 ovpnc2
192.168.10.0/24 link#2 U 0 1950883 1500 em1
192.168.10.1 link#2 UHS 0 0 16384 lo0

Firewall: Rules (pfsense1 и pfsense2)
OpenVPN:
IPv4 * * * * * * none
Lan:
IPv4 * LAN net * * * * none

Ping с pfsense1:
ответ на 10.0.8.1-есть
ответ на 10.0.8.6-есть
ответ на 192.168.10.1 (pfsense2)-нет
ответ на 192.168.10.100 (WS2)-нет

Ping с WS1:
ответ на 10.0.8.1-есть
ответ на 10.0.8.6-есть
ответ на 192.168.10.1 (pfsense2)-нет
ответ на 192.168.10.100 (WS2)-нет

Ping с pfsense2:
ответ на 10.0.8.1-есть
ответ на 10.0.8.6-есть
ответ на 192.168.1.1 (pfsense1)- есть
ответ на 192.168.1.100 (WS1)-есть

Ping с WS2:
ответ на 10.0.8.1-нет
ответ на 10.0.8.6-есть
ответ на 192.168.10.1 (pfsense2)-нет
ответ на 192.168.10.100 (WS2)-нет

P.S.
Проверяю на pfsense 2.1.5, на виртуальных машинах, шлюзы это ip противоположенных роутеров.

werter

2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.

Tr0tter

@werter:

2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.

а у меня без iroute всё видится)Как туда так и обратно, какспер только иногда всё прикрывает )

Groof

@Tr0tter:

@werter:

2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.

а у меня без iroute всё видится)Как туда так и обратно, какспер только иногда всё прикрывает )

Так у вас
@Tr0tter:

@werter:

У вас на сертификатах OpenVPN или на shared key построен?
Покажите скрин Certificates на сервере OpenVPN (pfsense).

shared key на клиентах вставлен shared key

У меня тоже с ним нету проблем, а тема о подключении OpenVPN p2p (SSL/TSL)

Groof

@werter:

2 Groof
Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.

Для начала хочу обратить внимание на странность, что с ws2 трафик так и не проходит в сеть pfsense1, хотя на pfsense2 есть маршрут в локальную сеть pfsense1 и к тому же трафик с самого pfsense2 проходит в сеть pfsense1.

Насчет указания директивы iroute на сервер openvpn в Client Specific Override, пробивал указывать
Disabled Common Name Description
NO ovpnc2 (iroute 192.168.10.0 255.255.255.0)
Указывал:
iroute 192.168.10.0 255.255.255.0

Но результат прежний, трафик не идет. И да правильно я понимаю что в Common Name нужно указывать интерфейс vpn подключения и в мое случаи ovpnc2 ?

werter

И да правильно я понимаю что в Common Name нужно указывать интерфейс vpn подключения и в мое случаи ovpnc2

Нет,не правильно.

http://fastinetserver.wordpress.com/2013/03/09/pfsense-openvpn-static-ip-for-clients/

NOTE: Common Name should be the same as specified in the clients certificate:

If you have forgotten this name go to System\Cert Manager\Certificates and check the value of the CN for your VPN use

Groof

@Groof:

Доброе. Подскажите кто в курсе, есть ли принципиальная разница в организации маршрутизации между подключениями по схеме OpenVPN p2p (share key) и OpenVPN p2p (SSL/TSL)?

Суть проблему в том, что при настройки по схеме OpenVPN p2p (share key), трафик между двумя роутерами на базе pfsense ходит без проблем, в том числе между рабочими станциями, которые находиться в локальных сетях за этими роутерами. Если я перенастраиваю только OpenVPN для работы по схеме и OpenVPN p2p (SSL/TSL), то трафик почему получается односторонним, причем только от клиента к серверу, от сервера к клиенту трафик уже не ходит не говоря о том что и нету трафика между рабочими станциями. При этом с маршрутизации все в порядке, на клиенте есть маршрут в сеть сервера, а на сервере есть маршрут в сеть клиента. Даже если открыть полностью файрвол, то проблема останется. В чем может быть дело?

@werter:

Есть ли директива iroute на сервере OpenVPN. Она необходима, чтобы сеть за сервером могла видеть сеть за клиентом.

Спасибо за разъяснение. Был невнимателен. Действительно нужно было указать подсеть клиента с помощью директивы iroute на сервер в Client Specific Override, где в Common name, нужно было указать Common name из сертификата клиента.

Tr0tter

А как завернуть сеть в сеть которые за VPN находятся ? что бы сети друг друга "знали" ?

pigbrother

@Tr0tter:

А как завернуть сеть в сеть которые за VPN находятся ? что бы сети друг друга "знали" ?

Если имеются в виду подсети за OVPN-клиентами, подключенными к "центральному"OVPN-серверу, то указать каждой подсети маршрут в другую подсеть:

На клиентах в Advanced configuration
route 192.168.Х.0/24 255.255.255.0

или, если на сервере используется конфигурация PKI - в Client Specific Overrides
push route "192.168.Х.0 255.255.255.0"

где 192.168.Х.0 - сеть удаленного филиала

В редких случаях push route может оказаться нужным дополнить явным указанием шлюза:
push route "192.168.Х.0 255.255.255.0 10.х.х.1"

где 10.х.х.1 адрес OVPN-сервера в туннеле

Не лишним может оказаться добавление на LAN на сервере и клиентах правил вида

IPv4 * LAN net * 192.168.Х.0/24 * * none

Обратите внимание на **IPv4 *** - по умолчанию правило создается только для TCP

Tr0tter

@pigbrother:

@Tr0tter:

А как завернуть сеть в сеть которые за VPN находятся ? что бы сети друг друга "знали" ?

Если имеются в виду подсети за OVPN-клиентами, подключенными к "центральному"OVPN-серверу, то указать каждой подсети маршрут в другую подсеть:

На клиентах в Advanced configuration
route 192.168.Х.0/24 255.255.255.0

или, если на сервере используется конфигурация PKI - в Client Specific Overrides
push route "192.168.Х.0 255.255.255.0"

где 192.168.Х.0 - сеть удаленного филиала

В редких случаях push route может оказаться нужным дополнить явным указанием шлюза:
push route "192.168.Х.0 255.255.255.0 10.х.х.1"

где 10.х.х.1 адрес OVPN-сервера в туннеле

Не лишним может оказаться добавление на LAN на сервере и клиентах правил вида

IPv4 * LAN net * 192.168.Х.0/24 * * none

Обратите внимание на **IPv4 *** - по умолчанию правило создается только для TCP

Тобишь, если имеется сервер с IPv4 Tunnel Network 172.16.1.0/24 нужно в Advanced добавить помимо вот этого push "route 192.168.0.0 255.255.255.0";
route 192.168.100.0 255.255.255.0; ещё и push route "192.168.5.0 255.255.255.0 172.16.1.0 ? Сеть от 5 заворачиваем через 172.16.1.0 в 100 ? это на одном сервере, тоже самое на другом, только тунель будет другим ?

pigbrother

Забудьте про адресацию туннелей. Для туннеля ваша единственная задача - обеспечить уникальную (неиспользуемую ни в какой реальной подсети адресацию, которая работает\будет работать в OpenVPN.
После того, как туннель поднялся все настройки производятся с реальными адресами подсетей, шлюзов и т.д.

это на одном сервере, тоже самое на другом, только тунель будет другим ?
Давайте уточним терминологию.
Сервер - это то, что ожидает подключения.
Клиент - это то, что инициирует подключение.

В случае PKI ("сервер с сертификатами") настройки сервера в client specific overrides в принципе равнозначны настройкам на клиенте.
Например push route "…. в client specific overrides делает то же самое, что route в настройках клиента.
Исключение - директива iroute, ее нужно указывать именно в client specific overrides на сервере.

Tr0tter

@pigbrother:

Забудьте про адресацию туннелей. Для туннеля ваша единственная задача - обеспечить уникальную (неиспользуемую ни в какой реальной подсети адресацию, которая работает\будет работать в OpenVPN.
После того, как туннель поднялся все настройки производятся с реальными адресами подсетей, шлюзов и т.д.

Ну и где это делается ? из сети 192.168.0.0 я могу пинговать всё что можно, а вот из 192.168.5.0 не могу пинговать 192.168.100.0 но из этих сетей я могу пинговать 192.168.0.0