Comments 50
Мы отказались от создания сети при помощи OpenVPN с использованием маршрутизации из-за чрезмерной громоздкости архитектуры подобных сетей. На наш взгляд, самый простой и удобный вариант — это одноранговая сеть.
А что вы пронимаете под «громоздкостью»? А широковещательные пакеты не сильно мешают?
А что вы пронимаете под «громоздкостью»?
Необходимость обеспечивать эту самую маршрутизацию на каждой точке сети, плюс обслуживание маршрутизаторов. Без оной наращивание сети происходит намного проще, что нам и нужно.
А широковещательные пакеты не сильно мешают?
Они нужны некоторым нашим подсистемам.
Необходимость обеспечивать эту самую маршрутизацию на каждой точке сети, плюс обслуживание маршрутизаторов.
Вовсе нет, достаточно только на точках обмена трафиком.
Они нужны некоторым нашим подсистемам.
И они не сильно мусорят на ВСЮ шифрованную одноранговую сеть?
Вовсе нет, достаточно только на точках обмена трафиком.
Это если точка обмена трафиком является шлюзом по умолчанию. А это не так.
И они не сильно мусорят на ВСЮ шифрованную одноранговую сеть?
Нет. :)
Это если точка обмена трафиком является шлюзом по умолчанию. А это не так.
а тогда какая маршрутизация имеется в виду?
Допустим, у нас всего 3 сети: 10.0.1.0/24 (2 сервера), 10.0.2.0/24 (10 серверов), 10.0.3.0/24 (3 сервера)
Каждый сервер имеет внешний IP и внешние сервисы. Т.е default gw wan.
Объединяем их при помощи OpenVPN без построения общей локальной сети.
Получаем, например, связи: 10.0.1.1 — 10.0.2.1, 10.0.2.1 — 10.0.3.1
Теперь как 10.0.3.2 узнает куда ему девать пакеты для 10.0.2.4 или 10.0.1.2?
Самый простой способ прописать ему маршруты на 10.0.2.0/24 и 10.0.1.0/24 через 10.0.3.1. Иначе он их бросит на wan.
Каждый сервер имеет внешний IP и внешние сервисы. Т.е default gw wan.
Объединяем их при помощи OpenVPN без построения общей локальной сети.
Получаем, например, связи: 10.0.1.1 — 10.0.2.1, 10.0.2.1 — 10.0.3.1
Теперь как 10.0.3.2 узнает куда ему девать пакеты для 10.0.2.4 или 10.0.1.2?
Самый простой способ прописать ему маршруты на 10.0.2.0/24 и 10.0.1.0/24 через 10.0.3.1. Иначе он их бросит на wan.
а 10.0.3.2 — клиент у OpenVPN или нет?
Нет. Он как раз про VPN ничего и не знает.
а как тогда он к одноранговой сети будет подключён?
Статья как раз об этом. :) Собственно объединение делает описанный выше скрипт /etc/init.d/lan0
Для одноранговой сети мы используем единую сетевую адресацию. Если рассматривать тот же пример, то придётся расширить маску до /16.
И вот тогда пакет от 10.0.3.2 до 10.0.2.4, например, пойдёт по lan, проскочит по мосту на 10.0.3.1, затем по такому же мосту на 10.0.2.1 и попадёт на lan 10.0.2.4. И без всякой маршрутизации.
Для одноранговой сети мы используем единую сетевую адресацию. Если рассматривать тот же пример, то придётся расширить маску до /16.
И вот тогда пакет от 10.0.3.2 до 10.0.2.4, например, пойдёт по lan, проскочит по мосту на 10.0.3.1, затем по такому же мосту на 10.0.2.1 и попадёт на lan 10.0.2.4. И без всякой маршрутизации.
Статья как раз об этом. :) Собственно объединение делает описанный выше скрипт /etc/init.d/lan0
Для одноранговой сети мы используем единую сетевую адресацию. Если рассматривать тот же пример, то придётся расширить маску до /16.
Я пропустил выделенный фрагмент комента в самой статье.
НО ведь вам тогда придётся менять сетевые настройки всех серверов.
ЗАЧЕМ тогда объединять ЦОДы по L2, тем более что адресные пространства не пересекаются? Я вижу одну причину: «чукча не умеет / не знает как делать правильно» (уже имеющимися средствами это делается за несколько минут). Вы не упростили, а, наоборот, серьезно усложнили себе жизнь. L2 DCI, тем более на 6 узлов, как раз наиболее сложная топология, требующая серьезного планирования, под это даже специальные стандарты разрабатывают. IPoEoMPLSoGREoIP например для транспорта — не потеряв резервирования, исключить прохождение лишнего трафика между площадками, изолировать домены STP, в общем и целом — убрать влияние одной площадки на другие; приблуда для отъема у IP адреса роли идентификатора местоположения узла в сети для обеспечения оптимальной маршрутизации входящего трафика, иначе он скакал бы как бешеный между площадками, создавая бешеную нагрузку на каналы.
Нет идиотов просто взять и соединить все площадки транками. Ну по крайней мере я раньше так думал.
И нет ничего проще, чем банальная L3 связь между площадками — легко обеспечить любое резервирование и любое масштабирование каналов; легко сопровождать; практически невозможно сломать.
Если бы я был вашим клиентом — прочитав такой пост, я бы к настоящему моменту уже перестал быть вашим клиентом. Просто на всякий случай.
Нет идиотов просто взять и соединить все площадки транками. Ну по крайней мере я раньше так думал.
И нет ничего проще, чем банальная L3 связь между площадками — легко обеспечить любое резервирование и любое масштабирование каналов; легко сопровождать; практически невозможно сломать.
Если бы я был вашим клиентом — прочитав такой пост, я бы к настоящему моменту уже перестал быть вашим клиентом. Просто на всякий случай.
Мать моя женщина!
Эм… как забрать от вас свои домены?
Что мешало установить маршрутизаторы, которые бы справлялись с этой задачей намного продуктивнее? Теже Mikrotik например?
Да, именно железные маршрутизаторы, пароли на настройки которых знает только админ в центральном офисе. Ибо эникейщикам на местах в этих вопросах лучше не доверять.
От себя добавлю, что порекомендовал бы использовать TP-Link+openWRT. Мой знакомый, использующий mikrotik, затруднился с ответом на вопрос:
«сколько времени бизнес будет простаивать при аппаратном выходе из строя mikrotika»
От себя добавлю, что порекомендовал бы использовать TP-Link+openWRT. Мой знакомый, использующий mikrotik, затруднился с ответом на вопрос:
«сколько времени бизнес будет простаивать при аппаратном выходе из строя mikrotika»
Попутный вопрос — а чем обеспечивается надёжность и резервируемость рекомендованного вами решения?
Почему я предложил выбор микротика, так это из-за наличия решений в 1U корпусе, т.к. топикстартер ставит сервера в дата-центрах. Как известно, многие дата-центры запрещают использовать не юнитовое оборудование.
А на счёт аппаратного выхода из строя микротика в дата-центре — поможет только наличие второго микротика рядом с сервером в этом же дата-центре. А если они стоят под боком, то достаточно иметь на складе несколько простых микротиков серии RB750, и копию конфигурации.
Почему я предложил выбор микротика, так это из-за наличия решений в 1U корпусе, т.к. топикстартер ставит сервера в дата-центрах. Как известно, многие дата-центры запрещают использовать не юнитовое оборудование.
А на счёт аппаратного выхода из строя микротика в дата-центре — поможет только наличие второго микротика рядом с сервером в этом же дата-центре. А если они стоят под боком, то достаточно иметь на складе несколько простых микротиков серии RB750, и копию конфигурации.
Сильная удалённость датацентров от нас и отсутствие собственного персонала в них, который бы смог заменить эти маршрутизаторы в случае необходимости. Простой в несколько дней — не самый лучший вариант развития событий.
При чтении очередной статьи не устану задавать «неудобные» вопросы:
1. Учёт «выбывших» ключей клиентов — в OpenVPN принцип разрешено что не запрещено — т.е. пока вы не внесете ключ в чёрный список — клиент может подключиться. А если вы не знаете сколько ключей выдано?
2. Одновременное подключение из двух мест под одним ключом — стандартно ситуацию невозможно диагностировать
1. Учёт «выбывших» ключей клиентов — в OpenVPN принцип разрешено что не запрещено — т.е. пока вы не внесете ключ в чёрный список — клиент может подключиться. А если вы не знаете сколько ключей выдано?
2. Одновременное подключение из двух мест под одним ключом — стандартно ситуацию невозможно диагностировать
UFO just landed and posted this here
1. Почему мы не знаем количество выданных ключей? Но даже если это внезапно случилось, то достаточно заглянуть в /etc/openvpn/keys. Удалить/заблокировать выбывший ключ, конечно же, придётся вручную. Но в чём здесь проблема?
2. Какова практическая ценность одновременных подключений? Тем более, что сеть в первую очередь объединяет серверы, а не людей.
2. Какова практическая ценность одновременных подключений? Тем более, что сеть в первую очередь объединяет серверы, а не людей.
1. Предыдущий админ мог сгенерировать и «взять с собой» ключ, не оставив ничего в /etc/openvpn/keys
Его ключ будет подписан CA, и сервер будет принимать подключения, а мы — не знаем что включить в black list
2. Ценности одновременного подключения никакой нет, просто если одно подключение с таким ключом уже установлено — повторное не будет устанавливаться, НО причину понять будет непросто.
Его ключ будет подписан CA, и сервер будет принимать подключения, а мы — не знаем что включить в black list
2. Ценности одновременного подключения никакой нет, просто если одно подключение с таким ключом уже установлено — повторное не будет устанавливаться, НО причину понять будет непросто.
Поэтому мы решили создать общую локальную сеть между всеми имеющимися серверами.
Мои глаза меня не подводят? Вы создаете шифрованные туннели между всеми серверами, терминируя их на самих серверах? Спасибо, теперь в моем личном рейтинге «самые кошмарные сетевые решения» появился новый лидер.
UFO just landed and posted this here
Но оно реально так и выгледит. Я несколько раз в голове строил сеть.
У меня только два решение
1) вы извращениц
2) вы ничего не понимаете в сетях и идете какоим то своим странным и долгим путем.
У меня только два решение
1) вы извращениц
2) вы ничего не понимаете в сетях и идете какоим то своим странным и долгим путем.
Но оно реально так и выгледит.
Вы ошибаетесь. Читайте внимательно.
JDima тоже либо не прочитал, либо не понял.
Приведенные конфиги мне мало о чем говорят, а текстовые пояснения слишком невнятны.
Но выводы-то далеко идущие это не мешает делать.
Того о чём вы пишите нет, не было и не будет.
Строятся каналы между существующими ethernet сетями в виде мостов. Каналы — OpenVPN, мосты — bridge-utils.
Того о чём вы пишите нет, не было и не будет.
Строятся каналы между существующими ethernet сетями в виде мостов. Каналы — OpenVPN, мосты — bridge-utils.
Между 6-ю ЦОДами? Тем более рад видеть данное решение в качестве лидера моего рейтинга. Особенно это умиляет ввиду того, что автор хочет 100% доступности, а сделал все, чтобы все 6 площадок могли лечь одновременно.
Всё также не поняли, но всё также не одобряете. ;)
Я прочитал habrahabr.ru/company/webnames/blog/162193/#comment_5574689 и вконец выпал в осадок. Ради интереса: сколько времени работает в IT человек, придумавший такое? У меня есть подозрение, что буквально вчера он услышал про такую прикольную штуку, как статический маршрут в серверной ОС, но так и не осилил концепцию маршрутизации. И наворотил нечто абсолютно несопровождаемое.
UFO just landed and posted this here
Эталонный пример, как делать не надо. По всем пунктам статьи.
Я только сейчас увидел в какой компании это реализовано. Как передать мои домены другому регистратору?
UFO just landed and posted this here
1. Для объединения территориально распределенных сетей существует протокол IP. И именно его и нужно использовать в вашем случае. Использование в этом качестве Ethernet over VPN over IP over Ethernet не самая лучшая идея. Проблемы: множественная инкапсуляция и все что из нее вытекает, сложность изменения дизайна сети, масштабируемость, отказоустойчивость, сложность фильтрации, мониторинга.
2. На основе тех же OpenVPN сложно, но тоже можно построить на L3 сеть. Есть чудесные опции
route, push «route/redirect-gateway
client-config-dir
ifconfig-push
iroute
Это вполне достаточный инструментарий для развертывания статической маршрутизации любой сложности.
3. Если статической будет недостаточно, можно использовать IPSec и OSPF например. Причем внедрять можно частично, не спеша, по сегментам, не мешая остальным.
2. На основе тех же OpenVPN сложно, но тоже можно построить на L3 сеть. Есть чудесные опции
route, push «route/redirect-gateway
client-config-dir
ifconfig-push
iroute
Это вполне достаточный инструментарий для развертывания статической маршрутизации любой сложности.
3. Если статической будет недостаточно, можно использовать IPSec и OSPF например. Причем внедрять можно частично, не спеша, по сегментам, не мешая остальным.
1. Проблемы более чем надуманные. Опыт показывает отсутствие оных с изменением дизайна, сложностью фильтрации и мониторинга. Масштабируемость — вообще большая проблема в IT — не претендуем на её решение. А отказоустойчивость… на практике стало лучше чем было.
А вот от подробностей проблем множественной инкапсуляции не откажемся.
2 и 3 — как раз те самые причины по которым от такого решения и отказались. Чуть более развернуто в диалоге с 4dmonster чуть выше.
А вот от подробностей проблем множественной инкапсуляции не откажемся.
2 и 3 — как раз те самые причины по которым от такого решения и отказались. Чуть более развернуто в диалоге с 4dmonster чуть выше.
Опыт? Расскажите про Ваш опыт фильтрации и мониторинга L2 трафика. Отсуствие проблем вследствии отсуствия фильтрации и мониторинга? )). Масштабируемость давно решена в протоколах, которые я описал выше. Отказоустойчивость из коробки в протоколах динамической маршрутизации. Отсутствие изменения дизайна сети… Вы вчера или позавчера запустили такой дизайн? Побуду Вангой, но предрекаю вам изменение дизайна сети, добавление\удаление новых хостов\площадок не позднее чем ближайший год.
Проблемы множественной инкапсуляции растут в прогрессии относительно уровней инкапсуляции. Сходу, напрмиер, измените MTU транспорта и дивитесь на метаморфозы. Подсказываю, OpenVPN не умеет корректно фрагментировать.
2 и 3 я делаю вывод «неосилили».
На вашем месте, я бы учился признавать ошибки, засел за курс CCNA (за 2 мес, вечером по 2 часа вполне можно осилить) и в своей работе опирался бы на многомиллионный опыт профессионалов, а не на свой, пока его еще нет.
Проблемы множественной инкапсуляции растут в прогрессии относительно уровней инкапсуляции. Сходу, напрмиер, измените MTU транспорта и дивитесь на метаморфозы. Подсказываю, OpenVPN не умеет корректно фрагментировать.
2 и 3 я делаю вывод «неосилили».
На вашем месте, я бы учился признавать ошибки, засел за курс CCNA (за 2 мес, вечером по 2 часа вполне можно осилить) и в своей работе опирался бы на многомиллионный опыт профессионалов, а не на свой, пока его еще нет.
А отказоустойчивость… на практике стало лучше чем было.
Расскажите, как реализованы:
1) резервирование каналов, каналообразующих систем (VPN сервера?) и сетевого оборудования.
2) изолирование сетевых сбоев на площадках (на примере простейшего: L2 луп).
1. OpenVPN серверов несколько. Они равнозначны. Находятся в двух ДЦ. Все на разных физических серверах. Из доп. сетевого оборудования используются только свичи. Там где серверов всего два — они соединены отдельным шнурком напрямую. Внешние каналы в компетенции датацентров.
2. В конфигах клиентов несколько записей remote. Один клиент подключается только к одному серверу в один момент времени. Самый большой сегмент не является клиентом ни для кого. L2 луп так никак не получится же.
2. В конфигах клиентов несколько записей remote. Один клиент подключается только к одному серверу в один момент времени. Самый большой сегмент не является клиентом ни для кого. L2 луп так никак не получится же.
1. Как резервируются сервера на остальных 4-х площадках? Как резервируются свитчи? Как резервируются аплинки от серверов до оборудования датацентра?
2. Луп можно вызвать даже специфической настройкой серверов (обычных, не VPN). И даже бывало, что гигабитная сетевушка на ровном месте начинает слать гигабит броадкастов, что примерно равносильно лупу. Как защищаетесь?
2. Луп можно вызвать даже специфической настройкой серверов (обычных, не VPN). И даже бывало, что гигабитная сетевушка на ровном месте начинает слать гигабит броадкастов, что примерно равносильно лупу. Как защищаетесь?
1. Конфиги для OpenVPN клиентов есть на всех серверах на остальных 4-х площадках. Но сам OpenVPN придётся запустить вручную.
Свитчи — никак.
От серверов до оборудования ДЦ ведут только патч-корды. Заменять их будут, если понадобится, сотрудники ДЦ.
2. От такого — никак.
Свитчи — никак.
От серверов до оборудования ДЦ ведут только патч-корды. Заменять их будут, если понадобится, сотрудники ДЦ.
2. От такого — никак.
Речь не о петле через впн-тунели, если появится петля на свиче? Любая поясняющая картинка сильно упростила бы дело, но как понял — какие-то свичи есть, к ним что-то подключено, раз «Нет. Он как раз про VPN ничего и не знает.» Вот там и может появится источник широковещательного шторма. Может это не будет петля в виде патчкорта из порта в порт. Может это будет неисправность свича в виде замыкания rx на tx или просто широковещательный флуд. Все это пойдет через мосты по тунелям на другие площадки. То, что этого не было до сих пор, не значит что вероястностью этого можно легко пренебречь. Я знал такие истории, когда тоже люди считали достаточно надуманной проблему и это сходило с рук годами. Зато когда это «выстреливает» — мало не кажется.
Cпасибо!!!
Смеялся до слёз!!!
Смеялся до слёз!!!
Sign up to leave a comment.
Локальная сеть глобального масштаба