OpenVPN PKI: Site-to-Site инструкция для обсуждения
-
утро доброе
Настроил канал согласно инструкции, сам канал поднимается, но подсети друг друга не видят, пр попытке трассировки всё валиться на первом шаге, то есть первая точка адрес tunnel network, далее пусто.
Фаерволы на обоих системах отключал, результат тот же. Не подскажете куда рыть?upd. Сам шлюз сервера видеться, пингуется, но компьютеры за этим шлюзом не видны,то есть проблема маршрутов, но куда ещё их прописать это вопрос.
-
Про правила на LAN не забыли?
https://forum.pfsense.org/index.php?topic=59081.msg606332#msg606332
-
Нет, всё прописал.
получается сервер 4.31 за ним клиенты
клиент 51.1 за ним клиенты
с стороны сервера клиенты 51.1-255 видны
с стороны клиента из подсети 51.1 виден только сетевой интерфейс 4.31
правила на обеих сторонах под опенвпн
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
0/58 KiB
IPv4 * * * * * * none
уже на стороне сервера написал принимать все соединения из подсети шлюзов 10.0.8.0/24
и принимать все что приходит с сетевого интерфейса на подсеть 4.0/22 это подсеть сервера
видимо где то затык в маршрутизации, подскажите где глянуть -
В принципе по приведенной ссылке инструкция, по которой все реально должно работать.
видимо где то затык в маршрутизации, подскажите где глянуть
Diagnostics/Routes
-
Доброе.
1. Шлюзами на обоих концах должны быть пф. Проверить.
2. Откл. временно антивирусы, fw на обоих концах . В том числе и встроен. в Вин.
3. Исп. волшебн. команду traceroute с обоих конфцов для поиска затыка. -
Доброе.
1. Шлюзами на обоих концах должны быть пф. Проверить.
2. Откл. временно антивирусы, fw на обоих концах . В том числе и встроен. в Вин.
3. Исп. волшебн. команду traceroute с обоих конфцов для поиска затыка.1. и да и нет, основную маршрутизацию выполняет другая железка, но мне кажется это не отменяет что pf должен выпускать в lan
2. уже делал не помогло
3. traceroute сделал сразу же, если роутить внутренний ресурс на серверной части сети то останавливается на виртуально ip адресе тунельного шлюза. Если посмотреть маршрут до 4,31 который и является серверной частью, то он вообще маршрут заканчивает на первом шлюзе, при этом сам 4,31 пингуется.В принципе по приведенной ссылке инструкция, по которой все реально должно работать.
Diagnostics/Routes10.0.8.0/24 10.0.8.1 UGS 0 1500 ovpns1
10.194.51.0/24 10.0.8.2 UGS 27 1500 ovpns1
10.0.8.2 link#7 UH 0 1500 ovpns1
все три маршрута верны в общем то
Первый это тунельный дипазон
второй подсеть клиента
третий сами понимаете. -
Скрины :
1. Certificates (сервер)
2. Правил fw на LAN.
3. Настройка vpn на сервере\клиенте.
3.1. Настройка Client specific overrides на vpn-сервере
4. Настройка NAT сервер\клиент.основную маршрутизацию выполняет другая железка
Зайдите на эту железку. Видна ли проблемная сеть с нее ?
-
Скрины :
1. Certificates (сервер)
2. Правил fw на LAN.
3. Настройка vpn на сервере\клиенте.
3.1. Настройка Client specific overrides на vpn-сервере
4. Настройка NAT сервер\клиент.основную маршрутизацию выполняет другая железка
Зайдите на эту железку. Видна ли проблемная сеть с нее ?
Проблема в том, что с стороны сервера я клиента и его подсеть вижу, а вот обратно не работает.
То есть с стороны клиента виден только интерфейс lan pf сервера.По изборажениям сейчас выложу, но мне кажется оно не поможет.
NAT везде включён на Automatic outbound NAT rule generation.
(IPsec passthrough included)На клиенте только адресь шлюза прописан и тунельная подсеть. Насколько я понял он должен по сертификату всё взять с сервера.
-
Скрин правил fw на клиенте не увидел. Или проглядел ?
У вас несколько LAN на сервере ? Или это в правилах fw на LAN сервера "каша" ?
Схему с адресацией , если можно, приложите.
Золотое правило:
В правилах fw на интерфейсах в src указываются только те сети, к-ые живут на этих интерфейсах.
Ни WAN, ни ВПН-сети в src на LAN в fw там не указываются (и наоборот).То есть с стороны клиента виден только интерфейс lan pf сервера.
Может все же виден ip впн-интерфейса пф, а не LAN ?
-
Скрин правил fw на клиенте не увидел. Или проглядел ?
У вас несколько LAN на сервере ? Или это в правилах fw на LAN сервера "каша" ?
Схему с адресацией , если можно, приложите.
Золотое правило:
В правилах fw на интерфейсах в src указываются только те сети, к-ые живут на этих интерфейсах.
Ни WAN, ни ВПН-сети в src на LAN в fw там не указываются (и наоборот).То есть с стороны клиента виден только интерфейс lan pf сервера.
Может все же виден ip впн-интерфейса пф, а не LAN ?
Нет на клиенте одно созданное всего, остальное по дефалту
там из LAN до подсети локально разрешить и всё.IPv4 * * * 10.194.51.0.24 * * none
Каша потому что очень много подсетей смашрутизировано до этого шлюза, тут прокся поднята, они все через неё ходят, а если запрос прилетает из неизвестной сети, его фаер лочит.
Видется именно локальный адрес интерфейса который смотрит в lan, не виртуальные адреса тунеля а именно 4,31 который физический, он пингуется и так далее, все остальные клиенты в сети не видны.скрины с клиенты
![Снимок экрана от 2016-12-05 17-49-59.png](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-49-59.png)
![Снимок экрана от 2016-12-05 17-49-59.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-49-59.png_thumb)
![Снимок экрана от 2016-12-05 17-50-10.png](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-10.png)
![Снимок экрана от 2016-12-05 17-50-10.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-10.png_thumb)
![Снимок экрана от 2016-12-05 17-50-26.png](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-26.png)
![Снимок экрана от 2016-12-05 17-50-26.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-26.png_thumb)
![Снимок экрана от 2016-12-05 17-50-44.png](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-44.png)
![Снимок экрана от 2016-12-05 17-50-44.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-44.png_thumb)
![Снимок экрана от 2016-12-05 17-50-53.png](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-53.png)
![Снимок экрана от 2016-12-05 17-50-53.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-53.png_thumb)
![Снимок экрана от 2016-12-05 17-50-58.png](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-58.png)
![Снимок экрана от 2016-12-05 17-50-58.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-05 17-50-58.png_thumb) -
Доброе
Покажите таблицу маршрутизации на клиенте при поднятом туннеле.И еще. Посмотрите на проблемной Вин-машине за клиентом, нет ли на ней руками заданных постоянных маршрутов.
На скрине в правилах fw server на LAN откл. (временно) выделенные желтым нижние правила - они не работают.
Самым верхним должно быть правило src - lan net , dst - сеть за клиентом. После него должно быть правило src - lan net, dst - * (any) по ip v4\v6На скрине в правилах fw client на LAN откл. (временно) выделенные желтым нижнее правило.
Самым верхним должно быть правило src - lan net , dst - сеть за сервером. После него должно быть правило src - lan net, dst - * (any) по ip v4\v6
-
На самом деле я думаю что не туда смотрим, ибо фаеры я все отрубал, картина не меняется
но сделал как вы сказали, скрин роутинга прикладываю, проблем там тоже не вижу, вроде как всё правильно![Снимок экрана от 2016-12-06 11-09-21.png](/public/imported_attachments/1/Снимок экрана от 2016-12-06 11-09-21.png)
![Снимок экрана от 2016-12-06 11-09-21.png_thumb](/public/imported_attachments/1/Снимок экрана от 2016-12-06 11-09-21.png_thumb) -
. и да и нет, основную маршрутизацию выполняет другая железка, но мне кажется это не отменяет что pf должен выпускать в lan
Что это за железка ? У нее шлюзом на ЛАН что указано ? Проверьте это
P.s. Сделайте проще. Поставьте шлюзом на ЛАН у одной из проблемных машин адрес пф. И проверяйте доступность.
-
. и да и нет, основную маршрутизацию выполняет другая железка, но мне кажется это не отменяет что pf должен выпускать в lan
Что это за железка ? У нее шлюзом на ЛАН что указано ? Проверьте это
P.s. Сделайте проще. Поставьте шлюзом на ЛАН у одной из проблемных машин адрес пф. И проверяйте доступность.
мда, как только указал шлюзом pf сразу пинги пошли, следовательно вопрос, как видеть машины в lan у которых pf не указан в качестве основного шлюза, но с которым они находятся в одной подсети
Как перенаправить запрос с сервера pf на другой шлюз? роутинг на pf настроен и когда на него приходит запрос на другую подсеть он сам перенаправляет, но когда запрос на другую подсеть идёт из клиента openvpn pf, сервер его никуда не перекидывает. -
Как вариант можно:
1. Добавить маршрут в удаленную сеть на каждой машине (в Windows- через route add) указав шлюзом LAN IP pfSense
2. Раздавать маршрут через DHCP:
https://forum.pfsense.org/index.php?topic=46210.0
https://social.technet.microsoft.com/Forums/ru-RU/e526fe6e-1bf4-42b9-a6e0-38f103e49a56/dhcp-2008r2-?forum=ws2008r2ru
Настройка может оказаться нетривиальной. -
Как вариант можно:
1. Добавить маршрут в удаленную сеть на каждой машине (в Windows- через route add) указав шлюзом LAN IP pfSense
2. Раздавать маршрут через DHCP:
https://forum.pfsense.org/index.php?topic=46210.0
https://social.technet.microsoft.com/Forums/ru-RU/e526fe6e-1bf4-42b9-a6e0-38f103e49a56/dhcp-2008r2-?forum=ws2008r2ru
Настройка может оказаться нетривиальной.ненене, подождите, зачем так грубо то.
у меня 4 кисковых шлюза под разные нужды, выход и как основной смаршрутизирован только один, тем не менее все клиенты что приходят в локалку с остальных шлюзов, все машины в локалке видят, отсюда вытекает вопрос:
Это принципиальная особенность pf чтобы видеть клиентов за шлюзом, они должны быть смаршрутизированы через этот шлюз? Или это я что то не докрутил? -
Это принципиальная особенность pf чтобы видеть клиентов за шлюзом, они должны быть смаршрутизированы через этот шлюз? Или это я что то не докрутил?
Это не свойство pfSense, т.к он за маршрутизацию в вашем случае вообще не отвечает.
выход и как основной смаршрутизирован только один
Вот он и должен разбираться с маршрутом в удаленную сеть.
В нем нельзя добавить статический маршрут в удаленную сеть с указанием шлюзом PfSense?
-
Это принципиальная особенность pf чтобы видеть клиентов за шлюзом, они должны быть смаршрутизированы через этот шлюз? Или это я что то не докрутил?
Это не свойство pfSense, т.к он за маршрутизацию в вашем случае вообще не отвечает.
выход и как основной смаршрутизирован только один
Вот он и должен разбираться с маршрутом в удаленную сеть.
В нем нельзя добавить статический маршрут в удаленную сеть с указанием шлюзом PfSense?
так отсюда всё видно
Проблема в том что клиент который за "клиентским" pf не видит местной локалки, опытным путём выяснено что клиентский pf с адресом 10,194,51,0/24 видит только те компы у которых в локалке 4,0/22 стоит шлюзом pfто есть
main network pf server pf client client network
4,0/22 –-------4,31 ---------10,194,51,1 ------ 10,194,51,0-255 работает
а обратно компы с адресами 10,194,51,0-255 не видят подсеть 4,0 то есть видят только если в качестве шлюза любому пк в подсети 4,0 указать 4,31. (при этом 4,31 как адрес виден)
Отсюда вопрос почему находясь в одной подсети с сервером pf компы должны иметь его как шлюз у себя, почему я просто не могу увидеть пк которые находятся с ним рядом в одной подсети -
Доброе.
Если связываете сети через впн, то видится они по умолч. будут только при указании шлюзов.
Или если руками (или по dhcp) на клиентах явно не добавлен маршрут в удал. сеть через туннель.И это не особенность пф - это особеность работы сетей вообще.
P.s. Оч. хорошо написанный цикл по сетям - http://linkmeup.ru/tag/сети%20для%20самых%20маленьких/. Спасибо ребятам.
-
Доброе.
Если связываете сети через впн, то видится они по умолч. будут только при указании шлюзов.
Или если руками (или по dhcp) на клиентах явно не добавлен маршрут в удал. сеть через туннель.И это не особенность пф - это особеность работы сетей вообще.
P.s. Оч. хорошо написанный цикл по сетям - http://linkmeup.ru/tag/сети%20для%20самых%20маленьких/. Спасибо ребятам.
Не соглашусь с вами, при прописывани маршрутов они отлично видятся, тут как раз вопрос к pf, а не к идеалогии vpn в целом.
Шлюзы все в pf указаны, вопрос не в указани шлюзов, вопрос в том, почему я конкретно должен указать шлюзом pf на клиентах чтобы видеть клиентов находяшихся рядом с ним?
~~Маршруты до всех подсетей прописаны в статических маршрутах, и при обращении к pf он нормально их дальше перекидывает, но почему то при соединении двух pf черзе openvpn этого не происходит, но это уже следующая песня.Обясните почему мне надо всех клиентов роутить через PF чтобы их было видно? У циски таких проблем нет. Возгласы так используйте везде циску сразу отметаю, ибо К9 поставить через таможню в почти все страны постсоветского оффициально не так просто.~~
Перечитал сообщение, не очень ясно написал.
PF находится в одной сети как я уже казал выше с рядом клиентов в подсети 4,0/24.
Если в качестве шлюза на клиентах указать сам pf тогда их видно с стороны подсети 10,194,51,0/22 которая подключена через vpn.
вопрос почему при прохожденииclient net pf client pf server local net
10.194.51.0/22 10.194.51.1 x.x.4.31 x.x.4.0/24я вижу только клиентов которые имею в качестве шлюза 4,31. почему я не вижу машин которые находятся за 4,31 если на клиентах в этой сети не прописан 4,31 как шлюз. при условии что статические маршруты на pf прописаны и работают в все подсети.
Вот прям даже картинку нарисовал
почему на клиенте 51,5 на картинке нет возможности достучаться до х.х.4.10. По сути на шлюзе 51,1 прописано где искать подсеть х.х.4.0/24. сам сервер PF находится в одной подсети с клиентом х.х.4.10 и имеет адрес х.х.4.31. Почему он его не видит? сервер openvpn PF не видит клиента с адресом х.х.4.10 находясь с ним в одной сети. При этом с самого сервера PF пинги до клиента х.х.4.10 идут. Но через openvpn этот клиент не виден. какой шаг пропущен? почему так получилось?
При этом клиент при обращении к другим подсетям через PF успешно уходит по указанным статичным маршрутам до х.х.4.1 и х.х.4.5. То есть маршрутизация работает, не работает что то между openvpn и pf. Вопрос что?Хорошо хрен с ним, давайте тогда форвадить весь трафик как вариант и использовать dhcp сервер в подсети 4,0/24, киньте в меня ссылкой если не сложно где это глянуть
-
Перечитал 5 раз пост.
1. Если у Вас не видит x.x.4.10 x.x.4.31 то значит у 4.10 стоит фаервол, который блокирует все, включая ICMP. Либо в настройках DHCP стоит галочка блокировать всех кроме статически заданных в таблице ниже.
2. А кто Вам сказал что шлюзом должен быть 4.31? шлюзом должен быть начальный адрес вашего тунеля IPV4 Tunnel Network (не путать с IP Server adress) для клиента. То есть при одном клиенте и сервере как правило используется x.x.x.0/30 подсеть (больший диапазон бесполезен), следовательно первый ип будет назначен серверной машине туннеля. Его и надо ставить в шлюз в роутинг параметрах для клиента. Соответственно во вкладке фаервола для OpenVPN должны быть разрешены все пакеты.
В параметрах нужно указать удаленные локальные сети. Либо в Advanced пишем руками route сеть маска сети.
3. Если Вы пытаетесь пинговать клиентов у которых не стоит в качестве шлюза 4.31 с компа у которого стоит в качестве шлюза 4.31,
Намек №1: тогда, может, стоит пинговать компьютеры у которых нет шлюзов с компьютеров у которых тоже нет шлюза?
@dmitry042:при условии что статические маршруты на pf прописаны и работают в все подсети.
Намек №2: А в компьютерах прописаны обратные статические маршруты во все сети? Или PF отправив пакет по маршруту должен от компа по его наитию получить ответ?
Намек №3: А может ну его этот шлюз, да пофигашить на всех компах, а маршурты все руками везде прописать…
@dmitry042:Не соглашусь с вами, при прописывани маршрутов они отлично видятся, тут как раз вопрос к pf, а не к идеалогии vpn в целом.
Прежде чем не соглашаться с опытными людьми, в начале, может, базовые правила маршрутизации почитать, на кои Вам скромно указали выше.
-
1. Внутри подсети х.х.4.0/24 всё клиенты видят 4.31. Тут всё ок
2. Из подсети х.х.4.0/24 все пакеты бегают отлично. Тут тоже всё ок
3.нет такой необходимости нет, согласно пункту 1. все компы в подсети х.х.4.0/24 видят друг друга вне зависимости от шлюза.Ёще раз, из подсети 10.194.51.0/22 видны машины подсети х.х.4.0/24 только на которых указан шлюз 4.31. В этом проблема, то есть машины на которых указан другой шлюз, но находящиеся в этой подсети х.х.4.0/24 из клиентской 10.194.51.0/22 не видны.
-
2 dmitry042
Доброе.
Только указание шлюзом пф поможет. -
Все правильно, откуда тот "другой" шлюз знает куда пакеты отправлять. Он к вашему каналу отношения то не имеет…
Есть какой то скрытый смысл в другом шлюзе? Может все через один шлюз завязать? -
Друзья, но ведь шлюз находится в одной подсети, и пк он видит.
Другой шлюз знает что надо отправлять пакеты до сервера pf который в подсети 4.0/24. Я просто логику не могу уловить.
и совершенно не понимаю что делать дальше в этой ситуации. -
пк он видит
И отправляет пакеты им.
А ПК отправляют свои ответы:1. Все, что не в локальную сеть - в шлюз по умолчанию.
2. Если им указан конкретный маршрут в другую сеть - в шлюз для этой сети. -
Читать теорию и статьи по маршрутизации и топологии сетей и как происходит прохождение пакета по сети. А тут задавать вопросы как это реализовать силами PF.
-
пк он видит
И отправляет пакеты им.
А ПК отправляют свои ответы:1. Все, что не в локальную сеть - в шлюз по умолчанию.
2. Если им указан конкретный маршрут в другую сеть - в шлюз для этой сети.2 страницы обсуждения, и ваш ответ мне помог, понял где затык, заранее спасибо!
Сейчас посижу подумаю как грамотнее описать маршруты, просто сеть сильно фрагменитрована, надо посидеть посмотреть предыдущие маршруты и какие то из них переписать.
В любом случае спасибо за ответ. -
2 dmitry042
Доброе.
Все же лучше свести все на один шлюз. Этим вы сильно облегчите себе жизнь. -
2 dmitry042
Доброе.
Все же лучше свести все на один шлюз. Этим вы сильно облегчите себе жизнь.А я и свёл, просто когда маршрут забивал одну лишнюю цифру в консоль уронил, утро всё же, вчера полез смотреть обратные маршруты, и точно.
Навело на мысль посмотреть фраза
А ПК отправляют свои ответы:
Ещё раз прошу прощения за долгий флуд, бывает такое взгляд замылился чтоли.
Спасибо огромное всем за помощь! -
Отличная, наверное, инструкция, но, только вот, скрины не открываются. А жаль…
-
Отличная, наверное, инструкция, но, только вот, скрины не открываются. А жаль…
Ув. @rubic переопубликовал скриншоты для инструкции для PSK.
Давайте попросим его, если скриншоты сохранились, сделать то же для PKI. В архивах\кэше сохраненной копии не нашел. -
Да, скрины бы очень не помешали. ::)
В ближайшее время несколько серверов предстоит поднимать.
Боюсь, что по памяти пропущу где-нибудь галочку-другую и потом буду удивляться почему не работает. -
приложил скриншоты
-
Здравствуйте. Есть PFsense (192.168.1.1 сеть 192.168.1.0/24) к нему по ovpn подключены два Mikrotika 192.168.2.1 192.168.2.0/24 и 192.168.3.1 192.168.3.0/24. Они пингуются оба из сети 192.168.1.1, но друг друга пропинговать не могут. Пытался добавлять iroute, нет результата. Подскажите возможно ли настроить маршрутизацию между ними если mikrotik-и подключены к разным opvn серверам.
-
1. В Client Specific Overrides для каждого клиента Микротика добавьте(измените) директиву в Advanced.
Через IPv4 Local Network/s это сделать невозможно.
push route "192.168.х.0 255.255.255.0 xx.xx.xx.1"где
192.168.х.0 255.255 - сеть за другим Микротиком
xx.xx.xx.1 - IP "серверного конца" OpenVPN-туннеляЛибо добавьте такой маршрут на каждом Микротике вручную.
2. На **OpenVPN-серверах может понадобиться **
добавить маршруты в сети за другими Микротиками, либо в IPv4 Local network(s) в виде 192.168.х.0/24 через запятую, либо route 192.168.х.0 255.255.255 в Advanced Configuration.У меня Микротики подключены к одному серверу, поэтому в необходимости п.2 не уверен.
-
Не подскажите как у вас настроено на одном сервере два микротика. У меня при этом пингуется только один из сети за pfsense-ом. Тот чья сеть указана в IPv4 Remote network(s) на сервере.
-
Не подскажите как у вас настроено на одном сервере два микротика. У меня при этом пингуется только один (пингуется из сети за pfsense-ом) . Тот чья сеть указана в IPv4 Remote network(s) на сервере.
Так сервер на то и сервер, чтоб обслуживать множество клиентов, не создавать же сервер для каждого.
То, что за клиентом - сеть, значения не имеет.Сервер
В IPv4 Remote network(s) - обе сети за Микротиками через запятую - a.a.a.a/24, b.b.b.b/24 (хотя я исторически использую вместо Pv4 Remote network(s) директиву route в advanced).Сlient Specific Overrides
Обязательно для каждого клиента Микротика в IPv4 Remote Network/s - сеть за этим Микротиком в виде a.a.a.a/24, а в Advanced
push route "b.b.b.b 255.255.255.0 x.x.x.1"
где
b.b.b.b 255.255.255.0 - сеть за другим Микротиком
x.x.x.1 - IP "серверного конца" OVPN туннеля. Это - ключевой момент, без него маршрут в сеть за другим Микротиком не будет воспринят.В IPv4 Local Network/s сети b.b.b.b быть не должно.
Для второго Микротика - по аналогии