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

vsop1

Прошу прощения за беспокойство. Сам накосячил - сам разобрался)

N3w4dm1n

на главном сенсе поднял сервер опенвпн 10.8.0.0/24 ->192.168.1.0/24, на клиенте так же все соответственно прописал как в инструкции с preshared key. но вот достучаться до главного офиса не могу. зависает на процессе connect to server IP.

надо ли в дополнительной конфиге прописывать правило хождения через сеть ван -> интернет -> главный офис?

KARLAGIN

Еще одни грабельки вырисовались. Имеем сеть из главного офиса и 10 удаленных, настроен OpenVPN все работает. Но имеем IP телефонию. Аппараты из удаленных филиалов стучатся на главный сервер ip телефонии в офисе по порту 5060. 90 случаев из ста все проходит хорошо, но в 10 случаях аппараты подключаются к атс по непонятным портам из разряда 1040-1050. В чем может быть загвоздка, можно ли в данном случае прописать что при обращении к 5060 он жестко передавался на 5060?

pigbrother

@N3w4dm1n:

на главном сенсе поднял сервер опенвпн 10.8.0.0/24 ->192.168.1.0/24, на клиенте так же все соответственно прописал как в инструкции с preshared key. но вот достучаться до главного офиса не могу. зависает на процессе connect to server IP.
надо ли в дополнительной конфиге прописывать правило хождения через сеть ван -> интернет -> главный офис?

Для начала:
Имеет ли сервер "белый" IP на WAN?
Если да, есть ли на WAN правило вида
TCP/UDP * * WAN address 1194 * none OVPN servers incoming rule

Где 1194 - порт, на который вы повесили OVPN-сервера
TCP или UDP выбирать, исходя из настроек сервере

НО:
Если WAN Получает IP вида 192.х.х.х. 10.х.х.х 172.16.х.х подключение о стороны WAN к такому серверу невозможно (либо потребуется пробрасывать порт со стороны провайдера)

Menog

сделал все как в первом посте
гл. офис - PfsenseServer - 192.168.2.0/24
филиал - PfsenseClient - 192.168.4.0/24
OVPN Tunneling - 192.168.8.0/24

В итоге
с самого PfsenseClientа видна вся подсеть 192.168.2.0/24, НО с компьютеров филиала под PfsenseClientом ничего не видно и не пингуется
с PfsenseServerа не пингуется PfsenseClient, и, соответственно с компьютеров под PfsenseServerом тоже….

Tracert 192.168.4.1 from PfsenseServer

Traceroute output:
1 * * *
2 * * *
3 * * *

Tracert 192.168.2.1 с компьютера филиала под PfsenseClientом

Traceroute output:
1 * * *
2 * * *
3 * * *

Tracert 192.168.2.1 с PfsenseClientа (что самое странное, т.к. 192.168.2.1, как и вся подсеть 192.168.2.0/24 нормально с него пингуется....)

Traceroute output:
1 * * *
2 * * *
3 *

Pfsense version 2.1.5

настройки Firewall идентичны, так что прилагаю скриншоты только с PfsenseServer

ovpn_server_client.png_thumb

ovpn_server.png_thumb
ovpn_client.png_thumb

ovpn_server_LAN.png_thumb

ovpn_server_WAN.png_thumb

ovpn_server_OVPN.png_thumb

ovpn_client_Routes.png_thumb

ovpn_server_Routes.png_thumb

werter

Что указано в кач-ве адреса шлюза на машинах за сервером и клиентом в их сетевых настройках ? Проверьте этот момент.

Далее, для того чтобы машины ЗА сервером увидели машины ЗА клиентом, необходимо, чтобы в настройках сервера во вкладке Client Specific Overrides присутствовала директива iroute - iroute 192.168.4.0 255.255.255.0;

И проверяйте traceroute доступность машин ЗА сервером\клиентом, а не адреса pfsense на обоих концах.

Совет. Смените с режим OpenVPN c P2P на Remote Access (SSL/TLS) - https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

Menog

iroute прописал, даже на клиентской части тоже
шлюзы везде норм - в филиале 192.168.4.1 в гл. офисе 192,168,2,1
Remote Access (SSL/TLS) на сервере поставил
в итоге мало что изменилось…..
трасерты таковы (на компах фаерволлы отключил)

client.png_thumb

server_comp.png_thumb

tracert_from_mainOffice.png_thumb

tracert_from_filial.png_thumb

werter

Покажите снова таблицу маршрутизации при установленном OpenVPN на сервере и клиенте.

P.s. У вас там еще и PPTP имеется? Или мне показалось ?

Menog

показываю,
PPTP отключил от греха

ах и ещё, если от клиентского Pfsense при трасерте поставить галочку use ICMP то он проходит (как и пинг, как говорилось изначально)

а так…до сих пор ничего не поменялось к лучшему....

мож какие packages могли бы мешать, но наврятли
но на всякий случай и их указываю...

ovpn_server_Routes_new.png_thumb

ovpn_client_Routes_new.png_thumb

tracert_from_filial_wICMP.png_thumb

packages_client.png_thumb

packages_server.png_thumb

rubic

@Menog:

сделал все как в первом посте

Вообще-то первый пост посвящен настройке OpenVPN в режиме "Peer to Peer ( Shared Key )", а не "Peer to Peer ( SSL/TLS )" как у вас на скриншотах.

Menog

не думаю, что в этом дело…
вопрос почему в Routing клиента
стоит:
192.168.2.0/24 192.168.8.5
когда должен по идее быть 192.168.8.1

и так же с сервером:

192.168.8.0/24 192.168.8.2
когда должен быть 192.168.8.6
т.к. в статусе OpenVpn клиенту дается именно адрес 8.6

Menog

Кароче плюнул на все и настроил ещё один Openvpn сервер уже под Shared Keys с сеткой туннеля 10.0.8.0
и вуаля
с филиала компы видят главный офис!!
но с офиса видно только PfsenseКлиента, а компы - нет.

если ставлю на главном Pfsense в Client Specific Ovverides - iroute 192.168.4.0 255.255.255.0
то вообще пропадает связь (с клиентов не вижу компы сервера) и в Routes сервера исчезает эта подсеть (4-я)


с клиентских компов:

tracert 192.168.2.20

Трассировка маршрута к DK [192.168.2.20]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  pfsense.tts2 [192.168.4.1]
  2     3 ms     2 ms     2 ms  10.0.8.1
  3     3 ms     3 ms     3 ms  DK [192.168.2.20]

Трассировка завершена.

с серверных компов:

tracert 192.168.4.1

Трассировка маршрута к 192.168.4.1 с максимальным числом прыжков 30

  1    <1 мс    <1 мс    <1 мс  pfsense.tts [192.168.2.1]
  2     2 ms     2 ms     2 ms  192.168.4.1

Трассировка завершена.

tracert 192.168.4.22

Трассировка маршрута к 192.168.4.22 с максимальным числом прыжков 30

  1    <1 мс    <1 мс    <1 мс  pfsense.tts [192.168.2.1]
  2     2 ms     2 ms     2 ms  10.0.8.2
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     *        *        *     Превышен интервал ожидания для запроса.
  5     *        *        *     Превышен интервал ожидания для запроса.
  6     *        *        *     Превышен интервал ожидания для запроса.

werter

@Menog:

не думаю, что в этом дело…
вопрос почему в Routing клиента
стоит:
192.168.2.0/24 192.168.8.5
когда должен по идее быть 192.168.8.1

и так же с сервером:

192.168.8.0/24 192.168.8.2
когда должен быть 192.168.8.6
т.к. в статусе OpenVpn клиенту дается именно адрес 8.6

Потому что динамически, т.е. OpenVPN сам решает какой адрес выдавать.

P.s. По поводу топологии OpenVPN (в самом конце) - http://rootstore.in.ua/content/pfsense_openvpn

Теперь вернемся к адресации в туннеле. Вообще говоря, OpenVPN поддерживает 3 топологии сети: p2p, net30 и subnet. Задать топологию сети можно в поле Advanced сервера. Например:

topology subnet

С топологией p2p мы уже знакомы по настройке сервера в режиме PSK. В режиме PKI по умолчанию используется топология net30. Создана она для обхода ограничения TAP-Win32 драйвера Microsoft в режиме эмуляции TUN интерфейса. Драйвер требует, чтобы в туннеле клиент и сервер находились в одной /30 подсети. Т.е. например сервер 10.0.8.1, клиент - 10.0.8.2. Ясно, что при таком ограничении сервер не сможет принимать подключения от нескольких клиентов, т.к. сеть /30 вмещает всего 2 эффективных адреса. Чтобы Windows могла работать с OpenVPN, на машине клиенте, образно говоря, создается виртуальный сервер, а на машине сервере – виртуальный клиент:

10.0.8.1 <–p2p--> 10.0.8.2 <=============p2p==============> 10.0.8.5 <--p2p--> 10.0.8.6

Адреса 10.0.8.1 и 10.0.8.2 укладываются в подсеть /30 и фактически находятся на pfSense1. При этом адрес 10.0.8.2 чисто виртуальный и символизирует собой удаленного клиента, в то время как адрес 10.0.8.1 – реальный и принадлежит локальной машине. Аналогично адреса 10.0.8.5 и 10.0.8.6 укладываются в подсеть /30 и фактически находятся на pfSense2. При этом 10.0.8.5 - виртуальный адрес, символизирующий удаленный сервер, а адрес 10.0.8.6 – реальный, принадлежащий локальной машине.

Если вы не собираетесь подключать Windows клиентов к OpenVPN серверу на pfSense, то можно использовать новую топологию subnet. В ней, если в настройках сервера в Tunnel Network стоит 10.0.8.0/24, то сервер получает адрес 10.0.8.1, а клиенты последовательно адреса 10.0.8.2, 10.0.8.3, …, 10.0.8.254. Одним словом, subnet. Если же вы собираетесь использовать OSPF над вашими туннелями в режиме PKI, то топологию subnet использовать нужно, т.к. в net30 OSPF работать не хочет.

Menog

ага, теперь почти понятно, спасибо большое ))

осталось только побороть видимость компов клиента с сервера (см. предыдущий мой пост)
добавляю роуты:

client_routes.png_thumb

server_routes.png_thumb

werter

Кароче плюнул на все и настроил ещё один Openvpn сервер уже под Shared Keys с сеткой туннеля 10.0.8.0
и вуаля
с филиала компы видят главный офис!!
но с офиса видно только PfsenseКлиента, а компы - нет.

если ставлю на главном Pfsense в Client Specific Ovverides - iroute 192.168.4.0 255.255.255.0
то вообще пропадает связь (с клиентов не вижу компы сервера) и в Routes сервера исчезает эта подсеть (4-я)

Необходимо еще в Client Specific Overrides правильно указать Common name - https://fastinetserver.wordpress.com/2013/03/09/pfsense-openvpn-static-ip-for-clients/

P.s. Рекомендую удалить ВСЕ Openvpn-ы на сервере и клиенте. После внимательно и неспеша создать их заново.

werter

добавляю роуты:

Стоп! Руками ничего добавлять не надо!
OpenVPN сам все решит. Если добавляли руками маршруты - удаляйте. И больше так не делайте.

P.s. Повторюсь :
Рекомендую удалить ВСЕ Openvpn-ы на сервере и клиенте. После внимательно и неспеша создать их заново.

Menog

под "добавляю роуты" имел ввиду добавляю скриншоты))

всеравно непонятно откуда брать Common name в Client Specific Overrides с учётом того, что я в этом сервере отказался от сертификации в пользу Shared Keys

rubic

В режиме PSK (Shared Key) "Client Specific Overrides" не нужны и не работают. У вас в первом посте было все хорошо, кроме режима. В частности все маршруты были на месте.

werter

@rubic:

В режиме PSK (Shared Key) "Client Specific Overrides" не нужны и не работают. У вас в первом посте было все хорошо, кроме режима. В частности все маршруты были на месте.

Прошу прощения. Ошибочно решил, что режим работы был сменен на Remote Access (клиент-серверный).

Menog

в общем все заработало без перестановки, всем огромнейшее спасибо)