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

[Призрак]

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

Выбор мой пал на pfSense. Отличный инструмент, с богатым функционалом, может быть установлен просто на флешку. Я уже его исследовал, обследовал, нашёл его болячки, проблемы, недостатки. Они для меня не существенны, польза перевешивает гораздо больше. Но появились дополнительные вопросы, которые я хотел бы задать, чтобы определиться окончательно. Обратите внимание, что эти вопросы не являются поводом для обсуждения чьих то умственных способностей в IT, я не прошу сделать за меня, я лишь спрашиваю, как удобно будет сделать.

1. OpenVPN. Очень хорошая реализация, богатые возможности для маршрутизации, очень гибкие настройки. У меня работают уже два шлюза, пока запасных, в отдельных корпусах. Связь между корпусами есть, достаточно стабильная, при этом я подключаюсь из дома, то есть создано у меня на одном шлюзе два сервера - один чисто для соединения pfSense, между собой, второй для подключения Windows шлюзов, а также из дома.

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

2. IPSec. Вот тут уже сложнее. Хотя я настроил на виртуальной машине соединение, между двумя шлюзами pfSense. Но лишь между двумя, а у меня всего пять корпусов. Можно создать туннели только между административным корпусом и всеми остальными, можно сделать что-то вроде "кольца", можно сделать перекрёстное соединение. Но мне важно чтобы я мог связаться, например, из общежития с лабораторным корпусом, а не заходить сначала в сеть административного корпуса, чтобы оттуда уже связаться с лабораторным, это неудобно.

Как лучше, если реализовать это? Тем более, я уже говорил, насчёт релея DHCP, мы пришли к выводу, что он не заработает на OpenVPN. Заработает ли он на IPSec? Мне это совершенно без разницы, так как я принял решение релей не использовать в общежитиях, а адреса указать вручную, так как там мало клиентов, а студентов обслуживает провайдер. Тем более, меня беспокоит, как подключаться в этом случае из дома? Если реализовать OpenVPN подключение из дома, а между корпусами IPSec.

Что скажете? Что посоветуете?

[ival]

По OpenVPN я промолчу, т.к. не использовал его никогда.

Выскажусь по IPsec:

Да он защищает, да он описан стандартами, есть понятные механизмы диагностики, да он универсален (есть некоторые проприетарные докруты) но есть НО...

IPSec сложен т.к.:

• это группа протоколов,
• IPSec строит два туннеля, и проблема с одним из туннелей ведет к определенным сложностям,
• IPSec имеет несколько режимов (туннельный/транспортный), что в свою очередь влияет на MSS и может привести к проблемам с фрагментацией
• и еще куча нюансов о которых надо знать. В IPSec не достаточно знать как настраивается он на конкретной железке, в IPSec надо знать именно принцип его работы и построения

Еще основной проблемой является не возможность использовать в чистом IPSec протоколы динамической маршрутизации. Это ведет в тому, что в IPSec нам приходится использовать дополнительные механизмы например GRE или проприэтарные VTI

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

В таких случаях можно использовать стандартный схему Hub and Spoke. Например: туннели GRE over IPSec + OSPF

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

1. OpenVPN. При всех достоинствах есть недостатки. Основной - он тормоз, даже при всех тюнингах и т.п. вы не раскочегарите его на всю ширину канала. Также он работает в userspace, что увеличивает нагрузку на железо, при большом пробегающем трафике может быть критично.

2. IPsec, как уже было сказано выше, основных недостатков два: он сложен и не позволяет использовать динамическую маршрутизацию.

Поэтому я тоже использовал бы GRE over IPsec, ну и OSPF было бы очень неплохо, но его сначала подучить надо. В такой связке можно тупо накидать "труб" между узлами, а OSPF уже сам разберется какой пакет какой дорогой пустить, а при пропадании одного из туннелей автоматически перестроит таблицу маршрутизации, по вновь открывшимся обстоятельствам.

[Призрак]

Хорошо, спасибо большое за информацию, я обязательно про всё это прочитаю. Я посмотрел, очень сложно, да. И очень большая неприятность в том, что почему - то тоннели не поднимаются, автоматически. Пишет status disconnected и кнопка connect. На виртуальном стенде. Это что же, мне после перезагрузки шлюза каждый раз бегать нажимать эту кнопку? Не очень то это и приятно.

[Призрак]

Всё, разобрался вроде. Чтобы тоннель поднялся, нужно прежде всего чтобы шёл трафик. Достаточно пинг сделать и тоннель заведётся.

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

1. Административный корпус главный, всё идёт через него, все тоннели. Дело в том, что вот для чего нам нужно виртуальное соединение - сотрудники получают почту, которая находится на почтовом сервере, в административном корпусе, также имеют доступ к 1С, а также имеют доступ к шарам.

2. Просто я делаю "кольцо", без главного. То есть, административный корпус соединяется с общежитием №2, общежитие №2 соединяется с лабораторным корпусом, лабораторный корпус с теоретическим, теоретический с общежитием №1, далее "кольцо" замыкается опять на административном корпусе.

[Призрак]

И ещё, мне сначала GRE интерфейсы создавать, потом их использовать в качестве основы для IPSec или как? с самим IPSec я почти разобрался, а вот как увязать с ним GRE у меня возникла небольшая путаница.

[Призрак]

На самом деле, я разбираюсь всё больше. Сначала надо создать GRE интерфейсы, с соответствующими правилами, потом уже IPSec. Я это понял как делать, да. Даже нарисовал предварительно простенькую схемку. Но вот чтобы соединить всё это, сколько интерфейсов GRE потребуется? Непонятно, к сожалению. На одном из узлов по любому придётся два клепать.

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

Сначала надо создать GRE интерфейсы, с соответствующими правилами, потом уже IPSec. Я это понял как делать, да.

Неправильно, в этом случае вы получите IPsec over GRE, вам нужно настроить IPsec в транспортном режиме, а туннели поднять при помощи GRE.

Вот одна из первых попавшихся ссылок на эту тему: https://uzlec.ru/ipsec-gre-vpn-s-rezervirovaniem-na-baze-pfsense.html там вроде бы все, что вам нужно.

. Просто я делаю "кольцо", без главного

Это плохой вариант. Лучше использовать соединения типа "звезда", а для наиболее часто используемых маршрутов кинуть дополнительные туннели, чтобы трафик ходил напрямую, минуя центральный узел.

[ival]

Не хотите Hub and Spoke, то делайте по своей схеме. Но в таком случае 100% лучше отказаться от статических маршрутов.

Для OSPF ваша схема должна выглядеть как на скрине ниже.
На всех маршрутизаторах интерфейсы туннелей GRE в ospf area 0
На R1 все локальные интерфейсы в ospf area 101
На R2 все локальные интерфейсы в ospf area 102
На R3 все локальные интерфейсы в ospf area 103
Также советую на шлюзах сделать Loopback интерфейсы с маской IP (Любой какой нравится из серой адресации и не пересекающиеся с имеющимися сетями) и маской 255.255.255.255 и добавить их в ospf area 0

На вашем рисунке не понятно почему интерфейсы WAN имеют серую адресацию (но это мне не особо интересно)

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

Лишние туннели пихать, потом запутается и в зонах и в туннелях. Начинать лучше с простого а потом наворачивать. Пусть лучше так как он нарисовал делает.

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

Лишние туннели пихать, потом запутается и в зонах и в туннелях. Начинать лучше с простого а потом наворачивать. Пусть лучше так как он нарисовал делает.

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

[ival]

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

Не принципиально, добавит еще свои 2 узла, и также сети туннелей в 0 зону, а локальные сети опубликует в отдельные зоны например 104 и 105.


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

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

Можно конечно и все сети пихнуть в 0, тогда ваше предложение будет работать и будет все просто "все в 0", но это не совсем правильно

А смысл делать несколько областей? Это когда сетей много правильно их разносить по областям, здесь пять сетей + VPN, все вполне поместится и в одну. Тем более что других маршрутизаторов внутри областей не будет.

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

Я бы сделал так. Соединил все сети звездой с Административным корпусом, а далее между собой кольцом.

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

Все это помещаем в единственную область OSPF, маршрутов и сетей тут немного, смысла выделять области я не вижу.

[Призрак]

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

Расклад такой. В административном корпусе находится мозговой центр, то есть там корпоративная почта, к которой сотрудники других корпусов должны иметь доступ, для получения писем, файловая шара с важными документами, вроде делопроизводства, консультант плюс, 1С бухгалтерия (для стоматологической клиники, столовых). Ко всему этому должны получать доступ некоторые сотрудники корпусов и общежитий. Везде, кроме двух общежитий есть контроллеры домена, которым очень важно проводить репликацию, между собой. Кроме того, в административном корпусе находится централизованное управление антивирусной защитой академии.

В общежитиях сотрудников мало, в основном на вахте, видео, система ОПС, которые должны быть, как и из других корпусов, отображаться на главном компьютере начальника службы безопасности, который находится в административном корпусе, столовые, комендант и заведующий общежитием, а также компьютерные классы и комнаты самоподготовки. Поэтому дополнительные контроллеры я там не предусмотрел, я лучше укажу DNS соседних корпусов, а также адреса вручную. У студентов сеть отдельная, они не имеют в нашу доступ, их обслуживает провайдер.

И, конечно, самое важнейшее это репликация. Нужно, чтобы она проходила, без проблем.

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

Та статья, что мне посылали, больно запутанная, к тому же она устаревшая, там всё замазано. Но ход мыслей я примерно понял. Что я должен буду сделать (на pfSense):

1. Создать и настроить на каждом шлюзе IPSec в режиме transport. Для WAN. Далее создать соответствующие правила сетевого экрана (не люблю, когда в руководствах разрешают всё и всем, делая дыру в безопасности, это не профессионально).

2. Создать и настроить GRE подключения. Для WAN. Указать адреса из сети 10.8.0.0. Далее создать соответствующие правила сетевого экрана (не люблю, когда в руководствах разрешают всё и всем, делая дыру в безопасности, это не профессионально).

3. Настроить на каждом узле Quagga OSPF. Я думаю, что это будет самое сложное. Надо будет разобраться, побольше.

Но тут у меня есть ещё один вопросик. Я настраиваю IPSec, потом пускаю GRE. Но не кажется ли, что в этом случае они будут работать параллельно, нет? Я то предполагал в IPSec указать интерфейсы GRE и затем уже адреса из сети 10.8.0.0.

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

Но тут у меня есть ещё один вопросик. Я настраиваю IPSec, потом пускаю GRE. Но не кажется ли, что в этом случае они

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

Грубо говоря было:

IP-заголовок | содержимое пакета

Стало

IP-заголовок | IPsec [содержимое пакета]

Я, конечно, могу подключить и так, мощностей шлюза в административном корпусе хватит, чтобы тянуть сразу всё. Но мне важно ещё одно. Например, я нахожусь в лабораторном корпусе. Мне сообщают, что в общежитии №2 неполадка. При такой схеме мне придётся подключаться сначала к административному корпусу, а потом к общежитию или же я сразу смогу, напрямую? К тому же я хочу подключаться из дома через OpenVPN и иметь доступ сразу ко всем корпусам и общежитиям.

Настроите маршрутизацию - сможете.


Вот я вам по OSPF хороший цикл статей нашел, не смотрите что он для микротик, там в первых частях хорошо теория изложена. Да и практика пригодится, сделаете по образу и подобию.

https://spw.ru/educate/articles/primenenie-ospf-v-routeros-1/

[Призрак]

Я бы сделал так. Соединил все сети звездой с Административным корпусом, а далее между собой кольцом.

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

Все это помещаем в единственную область OSPF, маршрутов и сетей тут немного, смысла выделять области я не вижу.

Вот я вам по OSPF хороший цикл статей нашел, не смотрите что он для микротик, там в первых частях хорошо теория изложена. Да и практика пригодится, сделаете по образу и подобию.

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

Но довольно оффтопа, с моей стороны. Докладываю, что я сделал, за текущее время. Вот во вложении схема, которую я собрал дома, на тестовом стенде. IPSec в транспортном режиме и GRE. Красная молния предполагает то, что я ещё могу добавить. При этом по сети 10.8.0.0 по GRE идёт пинг (я знаю, мне говорили, что отсутствие пинга ни о чём не говорит ещё, но, тем не менее, я этот инструмент ещё использую, для диагностики) от Gateway1 до Gateway2 и Gateway3, и, соответственно, от Gateway 2 и Gateway3 к Gateway1. Не идёт только от Gateway2 до Gateway3, но это легко исправить, установив маршруты или же реализовав ту красную молнию, что у меня на схеме (10.8.0.5, 10.8.0.6).

Далее мне нужно бы маршруты сделать, до сетей 192.168.5.0, 192.168.6.0, 192.168.7.0, что я с лёгкостью могу, вручную, прописав соответствующие правила в сетевом экране, а также настроить статические маршруты. Гораздо более интересно мне поиграться, конечно, с динамическими маршрутами, с Quagga OSPF, но тут я столкнулся с неожиданными проблемами, несмотря на то, что прочитал статью, которая с Mikrotik. Я прочитаю её ещё раз и ещё, но я не думаю, что мне удастся догадаться быстро, как всё это сделать.

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

1. По простому, что такое area?

2. Зачем создавать loopback интерфейс и как?

3. Какие мне нужно загнать интерфейсы в Quagga OSPF?

4. Я пытался включить два интерфейса GRE для Quagga OSPF, на Gateway1, но почему - то работает только один. Этот момент тоже непонятный.

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

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

1. Логическая область в рамках которой происходит обмен маршрутной информацией
2. Для назначения RID, при этом адрес на этом интерфейсе должен быть наименьшим. Можно не создавать, назначив RID вручную, можно вообще не трогать, только потом при отладке будет довольно тяжело разобраться кто есть кто.
3. Туннели и локальные сети, последние как passive, передавать в них маршрутную информацию нам не надо.
4. Что значит работают? Вы должны добавить в OSPF VPN-интерфейсы с типом Point-to-Point, тоже самое сделать на соседних роутерах, после чего они установят соседские отношения и начнут обмениваться маршрутной информацией.

[Призрак]

К бестолку. Первый интерфейс GRE 10.8.0.1 10.8.0.2 заводится. виден, но маршрута до сети 192.168.6.0 нет всё равно. Второй интерфейс GRE 10.8.0.3 10.8.0.4 по непонятной мне причине на Gateway1 не заводится, вообще, который должен вести к Gateway3 (OSPF not enabled this interface примерно так написано, хотя он добавлен). Я всё указал, кроме loopback интерфейса. Как я уже говорил, связь между сетями 10.8.0.0 есть, они видят друг друга, но, к сожалению, маршрутизация не работает, причём как я уже говорил в Gateway3 вообще не уходит. Придётся наверное маршруты вручную прописывать все, печально.

Маршруты не работают вообще в том плане, что отсутствует связь между сетями 192.168.5.0, 192.168.6.0, 192.168.7.0.

Я пробовал вчера работать, поднимается второй интерфейс GRE к Gateway3 только тогда, когда я меняю его сеть с 10.8.0.0. на 10.9.0.0, но при этом вообще связь пропадает, между 10.9.0.1 и 10.9.0.2 несмотря на то, что я прописываю правила.

[Призрак]

При этом очень любопытно, что интерфейс GRE на Gateway3 поднимается, с OSPF. Не связано ли это с конфликтом двух интерфейсов GRE на Gateway1, в OSPF? Странно.

[Призрак]

И как это они автоматически договариваются? Не верю. Всё равно ведь нужно что-то прописывать в секцию subnet to route иначе маршрут не виден. Удивляет весьма, если это пакет автоматической маршрутизации, то к чему эта мышиная возня я вообще не понимаю, с маршрутами. Всё равно, что этот пакет использовать, что вручную маршруты воротить. Ничего я не понял, всё прописал, как говорили. Главное GRE работает, IPSec тоже работает, тоннели поднимаются, трафик бегает, трудности только с этим несчастным Quagga OSPF. Тоже мне, инструмент. Логично было бы предположить, что если тоннели в сети видят друг друга, в сети 10.8.0.0. то и маршрутизация должна работать как следует. У меня правила в брандмауэре прописаны, я сто раз всё проверил. Неужели для того, чтобы работал второй несчастный интерфейс GRE на Gateway1 в Quagga мне придётся загнать его в подсеть 10.9.0.0? Сумасшествие.....

[ival]

Покажите sh ip ospf, sh ip ospf nei и sh ip ospf database.

[ival]

А смысл делать несколько областей? Это когда сетей много правильно их разносить по областям, здесь пять сетей + VPN, все вполне поместится и в одну. Тем более что других маршрутизаторов внутри областей не будет.

Смысл в магистральной зоне хранить конечные сети? Строить изначально нужно правильно. Сегодня это по одной сети за каждым маршрутизатором, а завтра за каждым еще появится пять сетей. Это конечно мелочь, но это бессмысленные LSA в 0 и бессмысленные простыни маршрутов. А вот наличие зон позволит и уменьшить количество LSA и при адекватной адресации на ABR'ах настроить суммирование.

[ival]

Извините, что все разными сообщениями, писал с телефона, а с него тяжело писать(( Добрался до компьютера прочитал все и дополняю

2. Зачем создавать loopback интерфейс и как?

2. Для назначения RID, при этом адрес на этом интерфейсе должен быть наименьшим. Можно не создавать, назначив RID вручную, можно вообще не трогать, только потом при отладке будет довольно тяжело разобраться кто есть кто.

ценность Lo не в использовании его как RID это скорее маленький бонус, а в том что этот интерфейс постоянно в состоянии UP. И при включении его в OSPF к маршрутизатору я могу подключиться по этому адресу через любой доступный интерфейс.

Вот не понимаю я, что со мной происходит, в последнее время.

Почему в схеме и у Административного и Теоретического один и тот-же адрес интерфейса 192.168.10.1?

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

Смысл в магистральной зоне хранить конечные сети? Строить изначально нужно правильно. Сегодня это по одной сети за каждым маршрутизатором, а завтра за каждым еще появится пять сетей. Это конечно мелочь, но это бессмысленные LSA в 0 и бессмысленные простыни маршрутов. А вот наличие зон позволит и уменьшить количество LSA и при адекватной адресации на ABR'ах настроить суммирование.

Я боюсь, что до этого топикстартеру еще рано, ему бы с одной областью ладу дать. Там всего пять сетей + VPN и расширения не планируется. Я бы сначала постарался завести все это хозяйство с одной областью, а потом уже шел бы дальше. Иначе там будет такой хаос, что лермонтовские "смешались в кучу кони, люди" покажется образцом порядка.

[Призрак]

Покажите sh ip ospf, sh ip ospf nei и sh ip ospf database.

К сожалению, ни одна из этих команд не сработала. Публикую что есть.

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

Вообще, я подумал, не использовать ли мне FRR? Вот, ролик я хороший на тему нашёл, но грош ему цена без схемы.

https://www.youtube.com/watch?v=4IlKcB17rWk

[Призрак]

Уважаемые! Если долго мучиться, что нибудь получится! Я поставил FRR. Я настроил глобальные настройки, а также OSPF, у меня всё завелось! Оказывается, что пакет Quagga OSPF не ставился почему - то корректно, не знаю почему! Вот, во вложении снимки экрана, маршруты есть!

Кроме того, я узнал, что BGP очень и очень сложный, я его не стал включать. Я просто настроил глобальные настройки FRR. Интерфейс мне очень понравился, особенно глобальные настройки. Вот тут понятно что и куда пихать, лишнее всё можно не включать, я и запихал туда сети. А из-за того что Quagga OSPF ставился некорректно, там половина опций отсутствовала, при этом он ставился почему - то так на всех клиентах. И пёс с ним.

Но похоже опять у меня остались вопросы.

Всё равно я не могу достучаться из одной сети в другую. Я знаю, что теперь дело в правилах брандмауэра, но не представляю пока, где мне их прописывать - в LAN или в VPN GRE интерфейсах. Раз маршруты есть, значит и сигнал должен уже проходить, всё ведь согласовано. По GRE он проходит.

Метрика маршрута. Как я понял, их нужно указывать для каждого интерфейса "навстречу". То есть, если я дал интерфейсу GRE1 на Gateway1 метрику 10, то и на клиенте Gateway2 для интерфейса тоже нужно давать метрику 10.

И, наконец, Area. Хоть бы небольшой пример накидать, там бы я уже понял.

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

Всё равно я не могу достучаться из одной сети в другую. Я знаю, что теперь дело в правилах брандмауэра, но не представляю пока, где мне их прописывать - в LAN или в VPN GRE интерфейсах. Раз маршруты есть, значит и сигнал должен уже проходить, всё ведь согласовано. По GRE он проходит.

Выключите брандмауэр и добейтесь работы без него.

Метрика маршрута.

Метрика участвует в вычислении стоимости маршрута наряду с рядом других параметров. Чем меньше метрика, тем выше приоритет этого интерфейса.

 

И, наконец, Area. Хоть бы небольшой пример накидать, там бы я уже понял.

И, наконец, Area. Хоть бы небольшой пример накидать, там бы я уже понял.

Это логическая область, по умолчанию уже существует магистральная область (area 0, backbone area) и все остальные зоны должны быть присоединены к ней. Теоретически запихивать свои сети в backbone не следует, для каждой группы сетей должна быть своя область. Но опять таки, деление на области делается сугубо логически, так как это удобно исходя из логики построения сети.


Для чего нужны области? При каждом изменении состояния узлов маршрутная информация заново распространяется в пределах области, что в свою очередь ведет к перестроению дерева путей. Т.е. увеличивается объем трафика и нагрузка на маршрутизаторы.

Между областями распространяется гораздо меньший объем маршрутной информации и изменения внутри одной области не затрагивает другие.

Проще говоря, одна область, это когда вы всегда знаете как пройти из точки A в точку Б, т.е. у вас проложен полный маршрут и все изменения на нем сразу отражаются в вашей системе. Разные области, это примерно так, чтобы пройти в точку Б вам нужно пройти, прямо, потом направо, а там стоит будка с информацией, в ней спросите.

Т.е. вы не нагружаете свою систему всем объемом маршрутов, а знаете только свои (сети в вашей области) и куда пойти спросить, если нужно пройти в другую область (пограничные маршрутизаторы, ABR).


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

Другая область - это другой город, карт которого у вас нет, но вы знаете, что вам нужно выехать из города на трассу через определенный выезд (пограничный маршрутизатор), но он тоже не знает как проехать на адрес и просто дает вам маршрут по трассе к другому городу (к другому пограничному маршрутизатору). Трассы между городами - это магистральная область, backbone area. Вы приезжаете в другой город (другая область) и на въезде получаете карту города с подробными маршрутами. Теперь вы знаете, как проехать в точку назначения.

[ival]

К сожалению, ни одна из этих команд не сработала.

Я не использовал pfsence, quagga или ffr, но эти команды должны присутствовать. Возможно надо как-то подключиться к VTY или настроить VTY в конфигах

[ival]

Всё равно я не могу достучаться из одной сети в другую. Я знаю, что теперь дело в правилах брандмауэра, но не представляю пока, где мне их прописывать - в LAN или в VPN GRE интерфейсах. Раз маршруты есть, значит и сигнал должен уже проходить, всё ведь согласовано. По GRE он проходит.

Тут зависит чем вы апеллируете зонами или интерфейсами. Обычно на туннельные интерфейсы аксес листы не ставят.

Метрика маршрута. Как я понял, их нужно указывать для каждого интерфейса "навстречу". То есть, если я дал интерфейсу GRE1 на Gateway1 метрику 10, то и на клиенте Gateway2 для интерфейса тоже нужно давать метрику 10.

Если менять с одной стороны, то с другой тоже необходимо сделать, чтобы маршрут ответа был аналогичен маршруту запроса. Проще всего регулировать командой ip ospf cost на конкретном интерфейсе

[Призрак]

В общем, увы и ах. Брандмауэр на шлюзах pfSense отключал, рисовал там разрешающие правила, никак не получается, всё равно соседние узлы по серым адресам не отвечают. Настораживают вот такие вот записи в конфигурационных файлах:

Gateway1 zebra.conf

Code Select Expand

password 123

# Accept Filters
ip prefix-list ACCEPTFILTER deny 192.168.5.0/24
ip prefix-list ACCEPTFILTER deny 192.168.5.1/32
ip prefix-list ACCEPTFILTER permit any
route-map ACCEPTFILTER permit 10
match ip address prefix-list ACCEPTFILTER
ip protocol ospf route-map ACCEPTFILTER
Gateway2 zebra.conf

Code Select Expand

password 123

# Accept Filters
ip prefix-list ACCEPTFILTER deny 192.168.6.0/24
ip prefix-list ACCEPTFILTER deny 192.168.6.1/32
ip prefix-list ACCEPTFILTER permit any
route-map ACCEPTFILTER permit 10
match ip address prefix-list ACCEPTFILTER
ip protocol ospf route-map ACCEPTFILTER
Gateway3 zebra.conf

Code Select Expand

password 123

# Accept Filters
ip prefix-list ACCEPTFILTER deny 192.168.7.0/24
ip prefix-list ACCEPTFILTER deny 192.168.7.1/32
ip prefix-list ACCEPTFILTER permit any
route-map ACCEPTFILTER permit 10
match ip address prefix-list ACCEPTFILTER
ip protocol ospf route-map ACCEPTFILTER
Выходит здесь мне надо искать причину? Заполнять access листы? Как я должен их заполнить, указать там те же маршруты, но с разрешением? Там всё пусто.

Почему в схеме и у Административного и Теоретического один и тот-же адрес интерфейса 192.168.10.1?

Виноват, исправил. Но здесь на форуме не могу уже поменять. У теоретического корпуса адрес 192.168.20.1

И вообще, для чего нужны там пароли? Тоже не совсем понятно.

Как делал диагностику - нахожусь я на первом клиенте, который имеет адрес 192.168.5.2. Делаю с него трассировку, до 192.168.6.2 и до 192.168.7.2 (это соседние клиенты, подключенные, соответственно, к Gateway2 и Gateway3). По трассировке видно, что первым прыжком идёт достижение шлюза, 192.168.5.1, затем тишина - превышен интервал ожидания для запроса. Брандмауэры выключены, на клиентах.

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

[ival]

Это route-map для фильтрации маршрута. В чем ее смысл я не могу понять, надо читать документацию. Предположу что она фильтрует маршруты полученные от frr. Пришлите полные конфигурированию zebra и frr, может станет понятнее.

По трассировке, можете показать список правил с pfsence? Если просто пинг запустите с этих машин какой ответ будет time-out или destination unreachable?

[ival]

Предположу что она фильтрует маршруты полученные от frr.

Похоже на правду
https://www.nongnu.org/quagga/docs/docs-multi/zebra-Route-Filtering.html

По мимо конфигов таблицу маршрутизации покажите с каждого GW и базу OSPF, только текстом пожалуйста а не скриншотом

[Призрак]

Пинг делал, не показывает ничего. Из консоли как прерываю, показывает, что столько то пакетов отправлено, 0 пакетов передано, 100% потерь.

При трассировке с клиента показывает первый хоп (прыжок) до шлюза, до серого адреса, затем превышен интервал ожидания для запроса.

Во вложении собрал информацию, по роутингу, пришлось запихать её в отдельный файл, очень много информации, на 30 с лишним страниц.

Маршруты тоже пришлось прикрепить во вложении, форум искажает таблицу.

Так же правила во вложении, слишком их много, это в шелле по команде. На самом деле, разрешающих их немного.

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

Code Select Expand

pfctl -d
И связь появилась, везде идёт пинг и трассировка. После включения сетевого фильтра снова всё пропало. Теперь мне осталось в правильном месте написать правило, которое позволит по нормальному поддерживать связь. Я считаю, что сетевой фильтр отключать непрофессионально, это делает систему очень уязвимой, в плане атак.

По OSPF теорию я прочитал. Вроде бы я понял, что есть главный маршрутизатор, а области лучше делать. То есть, вот в этой тестовой системе, которую я делаю у меня три узла, значит должно быть и три области? А если будет пять узлов, то и  пять областей? То есть вот так?
 
Gateway1 area 0.0.0.0
Gateway2 area 0.0.0.1
Gateway3 area 0.0.0.2

И вот ещё - есть возможность указать область конкретно, для интерфейса и в общих настройках область по умолчанию. Где это делать предпочтительнее? И в интерфейсе LAN если я указал, что он пассивный, надо указывать область и метрику?

И всё таки хотелось бы узнать ещё, про пароли. Для чего же они там нужны? И про метрики. Мне говорили, чем меньше метрика тем выше приоритет. Могу я назначить, например, если пять узлов, интерфейсам главного узла и тем интерфейсам шлюзов соседних, которые подключаются к главному узлу указать метрику, допустим, 1, а остальным узлам, где шлюзы соединяются между собой 2 и выше?

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

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

Зачем? Вам нужно обмениваться маршрутной информацией между 5 сетями, достаточно одной области. Можно даже все сделать в магистральной, хоть это и не по фен-шую. Хотя у вас все равно других областей нет и не предвидится. Грубо говоря, если в области только один роутер, то ее логический смысл теряется.

И снова. Нет главного маршрутизатора. Есть магистральная область и остальные. В них могут быть разные типы роутеров: внутренние, магистральные и пограничные (ABR).

И всё таки хотелось бы узнать ещё, про пароли. Для чего же они там нужны?

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

 

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

Можно, но зачем? В этом есть смысл, когда к одному и тому же узлу есть два пути с одинаковой стоимостью и если вы хотите по умолчанию гонять трафик именно этим маршрутом, то второму из них метрику стоит увеличить. Почитайте как вычисляется стоимость маршрута в OSPF.

[ival]

По ospf вопросов нет.

По поводу route-map:

Code Select Expand

# Accept Filters
ip prefix-list ACCEPTFILTER deny 192.168.6.0/24
ip prefix-list ACCEPTFILTER deny 192.168.6.1/32
ip prefix-list ACCEPTFILTER permit any
route-map ACCEPTFILTER permit 10
match ip address prefix-list ACCEPTFILTER
ip protocol ospf route-map ACCEPTFILTER
Скорее всего zebra фильтрует connected-сети. Предположу что это сделано, чтобы соседи ей не вбросили сети пересекающиеся с connected-сетями, защита от дурака.

По pfsence, сразу скажу, что я не работал с ним. Но из того что увидел - он апеллирует интерфейсами. Проще всего смотреть в логах при чем на конкретном интерфейсе

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