pfSense OpenVPN vs IPSec, проблема выбора.

[Призрак]

Что касается сети, делать буду так, как во вложении.

Что же касается трафика между серыми сетями в тестовом полигоне, я в полнейшей растерянности. Не знаю уже, что и делать. Дело в том, что я поставил такой эксперимент - только когда я выключал сетевой экран на обоих шлюзах, Gateway1 и Gateway2 командой

Code Select Expand

pfctl -d
То трафик начинал идти, аналогично и с Gateway3. Я сильно подозреваю, что там надо NAT настраивать. Так как когда я отключаю брандмауэр отключается и NAT.

Подтверждением тому служит то, что я во все абсолютно интерфейсы добавлял правила, ни в какую пакеты всё равно не идут, связи нет.

Таблицу NAT извините, что снимками экрана, иначе невозможно, там ещё и опции. Наверное, надо мне и это ещё как то настроить.

Пробовал NAT менять, опять разрешающие правила везде напихал, ни черта не выходит. Достало уже, честное слово. Если он GRE пропускает, с правилом, то какого фига он вообще пакеты не пропускает, в серую сетку? Журналы тупорылые, только на WAN интерфейсе показывает, что заблокировал, всё не то, на остальных молчок. Как так диагностику делать, не понимаю.

[Уваров А.С.]

NAT к маршрутизации между сетями никакого отношения не имеет. У вас явно проблемы с брандмауэром, насколько я понял, у вас там какие-то автоматические правила используются, зачем?

Как так диагностику делать, не понимаю

Прочитать документацию по брандмауэру во FreeBSD. По этой системе ничего не подскажу вообще.

[ival]

что такое gtog1?
Сделайте скриншот правил файрвала, может по скриншоту понять удасться. По тому что консольные правила которые вы скинули для меня темный лес.

[Призрак]

1. GTOG2 это интерфейс GRE на Gateway1 в сторону Gateway2

2. GTOG3 это интерфейс GRE на Gateway1 в сторону Gateway3

3. GTOG1 это интерфейс GRE на Gateway2 в сторону Gateway1

4. GTOG1 это интерфейс GRE на Gateway3 в сторону Gateway1

Как по схеме. Правила во вложении.

Насчёт автоматических правил это не ко мне, к разработчикам. Главное выключаю сетевой экран, связь есть. Включаю, связи нет. Шайтан. Было бы что понятно, а так вообще глухо всё.

[Уваров А.С.]

Там вообще то переключатель вверху есть и стоит он именно на создании автоматических правил.

[Призрак]

По умолчанию так и есть, как раз после установки. Я такой не ставил. А вот что пишет акула, на клиенте.

[Призрак]

Есть же вроде правила, которые разрешают из одной сети в другую. Даже есть соответствующие правила. Или я ошибаюсь?

[ival]

Коллеги я конечно не силён в pfsence, может у него своя логика, НО
Gre не должен натить, он вообще может быть IP address unnumbered. Чем он по вашему тогда пакет накрывать будет? Пустотой? Натить должен только wan

По архивным вложения завтра посмотрю, отпишу.

[Уваров А.С.]

Согласен, NAT должен быть только на WAN, для доступа клиентов сети в интернет. Для маршрутизации сетей NAT не нужен.

[ival]

Как по мне. На GRE должно быть any to any
В LAN у вас нет правил вообще, дефолтное правило разрешать из сети LAN куда угодно.
А где обратное правило для LAN сетей которые находятся за другими GW?

[Призрак]

На GRE сделаю тогда any to any.

В LAN у вас нет правил вообще, дефолтное правило разрешать из сети LAN куда угодно.

Тем не менее, я добавлял туда дополнительное правило. Не прокатывает.

где обратное правило для LAN сетей которые находятся за другими GW?

Не понимаю, что вы имеете в виду. Какое обратное правило. Если там есть разрешить всё и всем, куда угодно и откуда угодно. Это дефолтовые правила. И куда его запихать.

[ival]

Не понимаю, что вы имеете в виду. Какое обратное правило. Если там есть разрешить всё и всем, куда угодно и откуда угодно. Это дефолтовые правила. И куда его запихать.

На LAN интерфейск у вас нет правила ВСЕМ ВСЕ.
У вас есть правило разрешающие по протоколу IP локальным сетям интерфейса GW ходить везде
И есть правило отовсюду разрешать доступ к 80 порту LAN интерфейсу GW (например к 192.168.5.1)
Но нет правила с локальных сетей расположенных за соседними GW ходить в сети LAN net

Например на GW 1 по логике у вас должно быть правило

Protocol IPv4
Source 192.168.6.0/24 192.168.7.0/24
Port *
Destination LAN net
Port *
Gateway *

[Призрак]

К бестолку. Ничего не помогает. Я застрял. Правила все выставил, как мне указали. Ничего.

[Уваров А.С.]

У вас там в правилах какая-то дичь. Выключите автоматическое формирование правил, сделайте все руками.

IPsec не трогайте вообще, это транспорт. GRE - можно всем и везде. Это магистраль, фильтровать ее нет смысла.

Из локалки извне - можно всем. Извне в локалку можно ESTABLISHED, RELATED (это первым правилом), потом правила для доступа в локалку из других ваших сетей. Все остальное снаружи внутрь запретить.

При этом не путайте транзитный и входящий трафик. Первый идет от одного интерфейса роутера к другому, второй предназначен ему самому.

[ival]

К бестолку. Ничего не помогает. Я застрял. Правила все выставил, как мне указали. Ничего.

C интерфейсов GRE покажите правила

[Призрак]

C интерфейсов GRE покажите правила

Там, во вложении они есть, 38 пост. Начинаются на GRE. Где я скидывал все правила.

Попробовал VMWare Player, никак не получается, то же самое.

И есть проблемы, которые разработчики FreeBSD не удосужились исправить, до сих пор. Это очень печально. Система эта погибает, из года в год. Вот, подкинули мне две ссылки.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226411

https://redmine.pfsense.org/issues/4479

Вот ещё, масло в огонь.

https://www.linux.org.ru/forum/talks/13985603

Я сейчас пока обратил внимание на Linux IPFire, попробую, что из этого получится. Но и это не забываю. Может подскажете, что по этим ссылкам делать?

[ival]

Там, во вложении они есть, 38 пост. Начинаются на GRE. Где я скидывал все правила.

Вам после 38 поста написали переделать правила на GRE

[Призрак]

Я переделал их, уже, разрешил всё и всем, на GRE. Эффект тот же. Хорошо, вечером скину.

[Призрак]

Правила проверил, разрешено всё и всем, на GRE интерфейсах. Обидно, что ничего не получается, я уверен, что уж на этот раз я делаю всё правильно. Если уж я везде (!!!) прописываю разрешающие правила, то брандмауэр должен по всякому разблокировать пакеты, а он не разблокирует. Только при отключении брандмауэра пакеты начинают идти. Значит это 100% баг оси.

[Призрак]

В общем, надоело мне. Делал по этому видео, в точности, правда, маршрутизация у меня динамическая.

https://www.youtube.com/watch?v=YPYFcya3Qls&t=693s

Всё равно не завелось. Хоть что делай, хоть башкой бейся об стол, всё равно ничего не получается. Уничтожил всё, что создавал, дома. Все машины удалил, психанув. Всё, нет больше моего труда.

Если в программном продукте ошибка, страдать должен я, как всегда. Биться вечерами, ночами, ничего не получается и ничего не работает. Всё, я думаю, просто сделаю OpenVPN и всё, как и делал. Он, по крайней мере, работает хорошо.

[ival]

Вы NAT с gRE убрали??

[Призрак]

Не понял вопроса. Я могу убрать автоматические правила у NAT, но ведь что-то же там надо будет прописано.

[Уваров А.С.]

Я могу убрать автоматические правила

Это нужно было сделать еще давно.

[Призрак]

У меня получилось, наконец то! Только для этого мне пришлось пока сделать три условия:

1. Я сменил PFSense на OPNSense, эта система немного сложнее, но есть одно но - она не формирует дурацких автоматических правил, точнее у меня есть возможность их отключить (например, при создании IPSec тоннеля в расширенных настройках я могу поставить галочку "не применять автоматические правила"!) и писать самому, как и положено.

2. Я сменил протокол GRE, я про него много плохого читал, в том числе разговаривал с человеком, который работает с микротиками. Он мне ответил, что безобразный и глючный протокол, от использования которого он отказался. Я сменил на IPsec VTI. То есть на маршрутизируемый тоннель, а это о чём то уже говорит, поверьте. При этом создаётся сам отдельный интерфейс. Конечно, вы можете мне сказать, что плохому танцору мешает кое что, на это я отвечу, что на вкус и цвет товарищей нет.

3. Я пока что создал статические правила и ввёл вручную шлюзы. Трафик стал ходить, в ту и в другую сторону, всё отлично. Вот туториал.

https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-route.html

Теперь, я думаю, настало время разобраться с динамической маршрутизацией. Кто то мне обещал, что посоветует про area, в какие совать мне филиалы и зачем. А также я планирую снова использовать пакет frr, к quagga OSPF у меня доверие пропало.

Ещё одно преимущество OPNSense в том, что там не голые настройки, в консоли, в отличие от PFSense, нужно вводить пароль. Это даёт гарантию того, что даже при физическом доступе к шлюзу войти в систему из консоли будет невозможно, без пароля. А это ещё один бонус, к безопасности.

[Уваров А.С.]

сменил PFSense на OPNSense, эта система немного сложнее, но есть одно но - она не формирует дурацких автоматических правил

От перемены слагаемых... Весь вопрос именно в уровне владения системой. Насколько я видел на скриншотах, в PFSense автоматические правила тоже легко выключаются.

Я сменил протокол GRE, я про него много плохого читал, в том числе разговаривал с человеком, который работает с микротиками. Он мне ответил, что безобразный и глючный протокол, от использования которого он отказался.

Мда... GRE - это классика, простой и надежный как табуретка, что там "плохого" просто затрудняюсь представить.

Я сменил на IPsec VTI. То есть на маршрутизируемый тоннель, а это о чём то уже говорит, поверьте.

А GRE у нас давно не маршрутизируемый?

При этом создаётся сам отдельный интерфейс

Собственно как и у GRE.

Конечно, вы можете мне сказать, что плохому танцору мешает кое что, на это я отвечу, что на вкус и цвет товарищей нет.

Здесь соглашусь.

Теперь, я думаю, настало время разобраться с динамической маршрутизацией. Кто то мне обещал, что посоветует про area, в какие совать мне филиалы и зачем.

Мое мнение - вам хватит и одной области, даже магистральной. Но если делать по уму, то сделайте еще область и поместите туда свои сети.

Это даёт гарантию того, что даже при физическом доступе к шлюзу войти в систему из консоли будет невозможно, без пароля. А это ещё один бонус, к безопасности.

При физическом доступе к системе можете тушить свет и сливать воду.

[Призрак]

От перемены слагаемых... Весь вопрос именно в уровне владения системой. Насколько я видел на скриншотах, в PFSense автоматические правила тоже легко выключаются.

Правила NAT там всё равно автоматические, какие - то тупые, сами видели, на скриншотах.

Мда... GRE - это классика, простой и надежный как табуретка, что там "плохого" просто затрудняюсь представить.

А вы попробуйте ради интереса сами развернуть, на виртуальных машинах, только на pfSense. Я очень удивлюсь, если у вас получится. Может на линуксе это прокатывает, но я не знаю, сколько раз я писал, что с GRE на FreeBSD есть баг. А у меня ни времени, ни желания нет разбираться с этим багом, который не к чести разработчиков так и не исправили.

А GRE у нас давно не маршрутизируемый?

Не нужно цепляться к словам, я просто назвал один из режимов работы IPsec туннеля, а вы сразу так.

Собственно как и у GRE.

Он создаётся автоматически и сразу доступен, когда как для GRE приходится его создавать руками, ну на pfSense не пробовал создать IPsec VTI.

Мое мнение - вам хватит и одной области, даже магистральной. Но если делать по уму, то сделайте еще область и поместите туда свои сети.

То есть для административного корпуса 0.0.0.0, а для остальных 1.1.1.1?

При физическом доступе к системе можете тушить свет и сливать воду.

Честно говоря, это я не понял. Если есть доступ по SSH, то можно использовать его. А что плохого в пароле, на физическом доступе? Кроме нас там ещё персонал ходит, не хотелось бы, чтобы кто нибудь поигрался с настройками.

[Уваров А.С.]

Правила NAT там всё равно автоматические, какие - то тупые, сами видели, на скриншотах.

И на тех же скриншотах вверху виден переключатель, одна из позиций которого - не создавать автоматических правил.

но я не знаю, сколько раз я писал, что с GRE на FreeBSD есть баг. А у меня ни времени, ни желания нет разбираться с этим багом, который не к чести разработчиков так и не исправили.

Ссылку на незакрытый баг дадите? На багтрекере.

А вы попробуйте ради интереса сами развернуть, на виртуальных машинах, только на pfSense. Я очень удивлюсь, если у вас получится.

Вы не единственный пользователь pfSence и протоколу GRE лет в обед и он просто работает. У меня нет ни времени не желания возиться с pfSence, но беглый поиск в Гугле проблем не находит. В Linux и на Mikrotik GRE работает без лишних к нему вопросов.

Вообще ваши действия напоминают мне метания в стиле: не забивает гвозди молоток в красной ручкой, возьму вон тот с зеленой.

По хорошему, если выбрали какой-то продукт, то нужно изучать его до упора. А завтра у вас с OPNSense что-то не выйдет, куда побежите?

То есть для административного корпуса 0.0.0.0, а для остальных 1.1.1.1?

Зачем? Все в 1.1.1.1, магистральную область просто не трогаете.

А что плохого в пароле, на физическом доступе? Кроме нас там ещё персонал ходит, не хотелось бы, чтобы кто нибудь поигрался с настройками.

Если у меня есть физический доступ к железу с возможностью вставить флешку и загрузиться с нее, можете считать что никаких паролей у вас нет.

[Призрак]

Проблему решил, но частично. Я не знаю, как у вас там GRE работает, но я попробовал IPSec VTI и всё завелось. Маршруты указываю вручную, только тогда работает, связь появляется. Маршруты убираю, пробую настраивать через FRR OSPF, к бестолку, он даже не добавляет в базу данных соседний маршрутизатор. Кроме того, документация шлак, даже на английском читал, ничего непонятно, что где и куда. В журналах ничего нет, поэтому мне не удаётся никак интерпретировать проблему. Чудеса да и только. Продукт, который призван обеспечить удобства, наоборот, вставляет палки в колёса.

Вот две ссылки. Первая ссылка от руководства, по которому я настроил и всё превосходно работает. Только пришлось включить автозапуск тоннелей, везде баги, увы. Прописываю как есть, всё работает и пакеты идут, тоннели поднимаются.

https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-route.html

Вторая ссылка это попытка настроить маршрутизацию динамическую.

https://docs.opnsense.org/manual/dynamic_routing.html

Там есть ещё ссылка, на OSPFv2, в конце статьи, собственно, по ней и пытался настроить. Абсолютный бред тупого шизоида, к тому же он замазал сети, которые нужно добавлять, это в высшей степени гениальное руководство.

В общем, я так понял, что придётся маршруты писать вручную. Итог такой - маршруты не добавляются, роутеры в базу данных OSPF не добавляются. Печально. Но что же поделаешь, вручную так вручную, мне не привыкать.

[Призрак]

У меня всё получилось, с динамической маршрутизацией. Одну опцию я упустил только, если нужно, то я могу показать, как я это всё сделал. Там всё достаточно просто, требуется лишь указать интерфейс сетевой, IPSec с режимом точка-точка, сеть, которую использует IPSec и указать нормальный route redistribution, а также area. Всё работает, маршруты появляются, пинг гуляет.

В свою очередь на IPSec тоннелях нужно указать режим запуска немедленно, это даст гарантию, что тоннель поднимется.

[Призрак]

Опять пришлось к этой теме вернуться, так как остался ещё вопрос. Всё отлично работает, между двумя корпусами наладил связь уже, всё загружается, всё поднимается, пакеты ходят. Но вот у меня есть OpenVPN, сервер, на шлюзе OPNSense, в административном корпусе, который отлично работает, отдельно от IPSec, я подключаюсь к нему из дома. Но хотелось бы, чтобы, подключаясь по OpenVPN, я имел доступ ко всем корпусам, а не только к нему одному. Как это сделать правильно?

И ещё, я процитировал некоторые моменты.

И на тех же скриншотах вверху виден переключатель, одна из позиций которого - не создавать автоматических правил.

Теперь мне это не нужно. В OPNSense всё корректно, никоим образом не мешает работе NAT, чем я и доволен. Но я никогда не включаю теперь автоматические правила, всё пишу сам, руками.

Ссылку на незакрытый баг дадите? На багтрекере.

Для кого я пишу... Пост 50 этой темы, там все ссылки.

Вы не единственный пользователь pfSence и протоколу GRE лет в обед и он просто работает. У меня нет ни времени не желания возиться с pfSence, но беглый поиск в Гугле проблем не находит. В Linux и на Mikrotik GRE работает без лишних к нему вопросов.

И всё таки я не буду его использовать. Как раз мне на форуме pfSense дали ссылки, которые я публикую в посту 50 этой темы, значит есть. Мне главное чтобы исправно работало, а выискивать проблемы у меня нет ни времени, ни желания.

ообще ваши действия напоминают мне метания в стиле: не забивает гвозди молоток в красной ручкой, возьму вон тот с зеленой.

По хорошему, если выбрали какой-то продукт, то нужно изучать его до упора. А завтра у вас с OPNSense что-то не выйдет, куда побежите?

С этим вынужден не согласиться. Молотки могут быть разных производителей и, соответственно, разного качества, это вы тоже наверняка знаете. Один молоток сорвётся с ручки и прилетит вам в лоб, другой будет верным помощником на долгие годы. Насчёт изучения продукта - пользуетесь вы Windows XP. Долго пользуетесь, досконально его изучили. И тут вы с огорчением замечаете, что поддержка прекратилась! Зачем вам тогда эти знания? Я стараюсь лишних знаний не накапливать, это вредно.

Зачем? Все в 1.1.1.1, магистральную область просто не трогаете.

Вот с этим согласен, уже сделал, работает отлично, спасибо большое.

Если у меня есть физический доступ к железу с возможностью вставить флешку и загрузиться с нее, можете считать что никаких паролей у вас нет.

Вы думаете я не заметил подвоха в вашем вопросе? USB сервера можно отключить программно, а корпус сервера можно закрыть на замок, если открыть корпус, то сработает защита.

[Уваров А.С.]

Но хотелось бы, чтобы, подключаясь по OpenVPN, я имел доступ ко всем корпусам, а не только к нему одному. Как это сделать правильно?

Вариант 1. Ставите дома роутер с поддержкой OSPF и дружите его со своей сетью. На чем поднят канал при этом не важно.

Вариант 2. Прописываете роуты в конфиг сервера и передаете их на клиента.

[Уваров А.С.]

И всё таки я не буду его использовать. Как раз мне на форуме pfSense дали ссылки, которые я публикую в посту 50 этой темы, значит есть. Мне главное чтобы исправно работало, а выискивать проблемы у меня нет ни времени, ни желания.

Не буду спорить, я с BSD давно уже дел не имею, что там да как - не в курсе.

С этим вынужден не согласиться. Молотки могут быть разных производителей и, соответственно, разного качества, это вы тоже наверняка знаете. Один молоток сорвётся с ручки и прилетит вам в лоб, другой будет верным помощником на долгие годы.

В данном случае молотки отличаются именно цветом ручки, в обоих вариантах под капотом FreeBSD.

Насчёт изучения продукта - пользуетесь вы Windows XP. Долго пользуетесь, досконально его изучили. И тут вы с огорчением замечаете, что поддержка прекратилась! Зачем вам тогда эти знания? Я стараюсь лишних знаний не накапливать, это вредно.

А XP она в вакууме была? Опыт - вещь преемственная. Все то, что вы изучили в Windows 98/NT/2000/ХР/7 и т.д. пригодится вам в дальнейшем, преемственность пользовательского опыта сохраняется. Это же касается и Linux, и FreeBSD, особенно в части консольных команд, там преемственность ведет еще к седому UNIX.

Но есть особенности: в Debian-based свои, в RHEL-based свои. Поэтому следует изучать какое-то одно семейство, чтобы не распыляться. Тоже самое касается и специфичных дистрибутивов, типа pfSence и т.д., там везде свои погремушки. Поэтому изучать также лучше что-то одно, а еще лучше - базовую систему, тогда вам будет все равно на надстройки и вы сможете разобраться с любой производной.

[Призрак]

Связь остаётся отличная, пока настроил между двумя корпусами, канал держит, соединение не падает, маршрутизация работает. Перезагружал первый маршрутизатор, второй, оба вместе, канал поднимается.

Но вот остались ещё всё - таки вопросы.

Вариант 1. Ставите дома роутер с поддержкой OSPF и дружите его со своей сетью. На чем поднят канал при этом не важно.

Вариант 2. Прописываете роуты в конфиг сервера и передаете их на клиента.

Вариант 1, конечно, хорош, но мне не одному надо подключаться к сети, у нас это несколько сотрудников делают, из дома. Кроме того, нужен ведь ещё IP адрес белый, постоянный дома, а за это надо платить отдельно. И, кстати, не у всех сотрудников есть такие дома маршрутизаторы, с OSPF.

Вариант 2 заставил меня поломать голову, но я так и не решил пока вопрос. Дело в том, что почему - то маршруты, прописанные в конфиге сервера, не работают. Даже в специфических опциях (ccd). Сеть IPSec VTI + OSPF у меня 10.7.0.0, а OpenVPN 10.0.9.0. Как подружить эти две сети я пока не понимаю.

Во вложении два корпуса. Первый корпус, 10.0 там OpenVPN сервер, соответственно, с интерфейсом ovpns2. Второй корпус 20.0, любопытно очень, что там OSPF маршрут 10.0.9.2, через ipsec, хотя нигде он не прописан, и в сетях в настройке OSPF не указан.

[Уваров А.С.]

Кроме того, нужен ведь ещё IP адрес белый, постоянный дома, а за это надо платить отдельно.

Не нужен. Достаточно белого IP со стороны сервера.

Дело в том, что почему - то маршруты, прописанные в конфиге сервера, не работают. Даже в специфических опциях (ccd).

Наверное потому, что они неправильные.

Сеть IPSec VTI + OSPF у меня 10.7.0.0, а OpenVPN 10.0.9.0. Как подружить эти две сети я пока не понимаю.

А зачем их "дружить"? Это транспорт, они вообще не должны знать друг про друга.

Вам нужно передать с сервера маршруты к вашим сетям, например:

Code Select Expand

push "route 192.168.1.0 255.255.255.0"
Сам сервер также должен располагать маршрутами к ним.

Если у вас VPN-клиент это конечный ПК, то больше ничего делать не надо. Если роутер и за ним домашняя сеть, то надо передать в ccd маршрут к этой сети:

Code Select Expand

iroute 192.168.2.0 255.255.255.0
Но здесь есть сложность, обычно домашние роутеры сидят в нулевой или первой сети, поэтому если таких сетей несколько - то ничего работать не будет.

[Призрак]

Всё сделал, как вы сказали, маршруты прописал, тишина. Когда я добавляю строчку

Code Select Expand

iroute 192.168.20.0 255.255.255.0
то появляется обведённое на снимке экрана в таблице маршрутизации OpenVPN. А в OSPF ничего не меняется и до 20 узла не достучаться, веб интерфейс не открывается. А вот если я пытаюсь достучаться через WEB интерфейс командами до 20.0 сети, у меня всё получается, сеть отвечает. И с клиента из 10.0 сети тоже получается достучаться. А дома у меня сеть 12.0

Это бы всё получилось, без сомнения, если бы на удалённых узлах у меня были настроены OpenVPN клиенты. Но у меня там только IPSec настроен, клиенты там не настроены. Вот я и хотел узнать, можно ли сделать так, чтобы OpenVPN работал через IPSec. А то я не думаю, что так целесообразно разворачивать параллельно IPSec ещё и OpenVPN клиентов. IPSec, кстати, работает не в режиме транспорта, а в режиме маршрутизируемого тоннеля. Вот как то бы маршрут прописать через сеть 10.7.0.0, тогда бы, я думаю, всё получилось бы. Но вот как. Напрямую до 20.0 явно не прокатит, так как на соседних машинах нет клиента OpenVPN, увы, только на моей домашней машине. До 10.0 сети из дома получается подключиться, потому что там OpenVPN сервер.