Комментарии 61
Не совсем понял с какой целью вы openvSwitch используете, объясните пожайлуста в чем преимущество перед: просто объединить мостом tap и физический интерфейс роутера? (насколько понимаю на шлюз прилетает транк, этот же транк отправляем через vpn тоннель). Или это для возможности гибкой настройки, какие валаны через vpn кидаем?
чтобы не делать отдельный тоннель для каждого vlan
На маршрутизатор приходят больше вланов, через openvpn пробрасываются только некоторые.
Решение получилось легко масштабируемым
Решение получилось абсолютно немасштабируемым (ибо растягивание L2 между площадками doesn't scale) и крайне неудобным в сопровождении.
Почему не выделили три отдельные сети под второй офис и не настроили маршрутизацию? Каков будет путь трафика из VLAN197 второго офиса в VLAN198 второго офиса? Как поживает MTU (на L2 не существует фрагментации и не существует PMTUD, а интернет обычно не пропускает более чем 1500 байт на пакет)?
А как решается вопрос с MTU и фрагментацией пакетов?
Вопрос с MTU, по-видимому, решается средствами туннеля, энкапсулированому трафику об этом знать не обязательно (пока тот же openvpn в состоянии фрагментировать и реассемблировать свои пакеты с учетом MTU транзита)
Маршрутизация, видимо, не вариант из-за каких-то специфичных приложений которым позарез нужно находится в одном широковещательном домене
Но, позвольте, почему не L2TPv3?
Маршрутизация, видимо, не вариант из-за каких-то специфичных приложений которым позарез нужно находится в одном широковещательном домене
Но, позвольте, почему не L2TPv3?
Потому что OpenVPN удобнее и проще в настройке, например.
подтверждаю предыдущего оратора, OpenVPN реально проще и удобнее для этого
ну и вообще остальные vpnы у него сосут по совокупности качеств
ну и вообще остальные vpnы у него сосут по совокупности качеств
Ну как решение из последних мне описание очень приглянулось у SoftEther VPN, но сам я его так и не попробовал.
Он довольно хорош, но, к большому сожалению, его тяжело настроить так, как нужно, по крайней мере, мне. Не поддерживает аутентификацию по сертификатам нигде, кроме своего протокола, тяжело настраивать через консоль, невнятные конфигурационные файлы, некоторым основным функциям уделено мало внимания, а некоторым второстепенным много. В целом, это хорошее решение, но какое-то не unix-way-ное.
А еще, его использовали террористы в аниме Zankyou no Terror.
А еще, его использовали террористы в аниме Zankyou no Terror.
Еще бы ему возможность p-2-p соединений, цены бы ему не было.
э… вы ман читали? Первая версия openvpn только peer-to-peer и была, это только во второй клиент-серверная появилась (но p2p никуда не делась)
Спасибо. Был неправ.
Но хочется большего — full-mesh, например.
Но хочется большего — full-mesh, например.
Да, full-mesh решений не хватает(
Tinc — вот вроде. Но реализовать отказоустойчивость с помощью двух провайдеров пока не получилось.
full-mesh — это cisco dmvpn. В принципе, есть его опенсорсная реализация в виде opennhrp (умеет до phase2, третью не умеет), но настройка — это геморрой, впрочем, не сильно больший, чем настройка его непосредственно на цисках
что значит отказоустойчивость с помощью двух провайдеров?
Tinc очень хороший и простой vpn, и mesh там реализован то же хорошо.
Tinc очень хороший и простой vpn, и mesh там реализован то же хорошо.
нет, что правда ip tun add gre123 mode gre… && ifconfig gre123 прямо таки сложнее и неудобней openvpn который надо ставить, обслуживать для него инфраструктуру ключей и плясать вокруг скриптовой обвязки?
он, конечно, местами хорош, но тезис о том что все остальные сосут мягко говоря категоричен
он, конечно, местами хорош, но тезис о том что все остальные сосут мягко говоря категоричен
во-первых, критика: если уж ip tun add, то давайте последовательно, ip link set, ip addr add и так далее
во-вторых, если бы это было сложно обслуживать инфраструктуру — можно было бы согласиться. Но easy-rsa решает. Это тривиально. А уж что касается скриптовой обвязки, то у openvpn по сравнению с gre-тоннелями вообще всё шоколадно
у gre есть своя ниша. Но это не готовое решение, в том виде, что вы привели его никто не использует, потому, что помимо gre потребуется ipsec и тут геморроя с шифрованием на порядок больше, чем openvpn. Полезно оно как компонент сложных серьёзных решений, типа dmvpn — там и раскрываются возможности gre (многоточковость, например)
во-вторых, если бы это было сложно обслуживать инфраструктуру — можно было бы согласиться. Но easy-rsa решает. Это тривиально. А уж что касается скриптовой обвязки, то у openvpn по сравнению с gre-тоннелями вообще всё шоколадно
у gre есть своя ниша. Но это не готовое решение, в том виде, что вы привели его никто не использует, потому, что помимо gre потребуется ipsec и тут геморроя с шифрованием на порядок больше, чем openvpn. Полезно оно как компонент сложных серьёзных решений, типа dmvpn — там и раскрываются возможности gre (многоточковость, например)
как по мне, easy-rsa это некий костыль для небольшого числа сертификатов.
Меня вот интересует, есть ли нормальные проекты в linux для управление огромным кол-вом сертификатов?
Меня вот интересует, есть ли нормальные проекты в linux для управление огромным кол-вом сертификатов?
Я недавно изучал этот вопрос. Пришел к выводу, что конкретно для VPN ничего удобней Easy-RSA v3 нет. Если интересно, я сделал версию, которая корректно работает и с IPsec
github.com/ValdikSS/easy-rsa-ipsec
github.com/ValdikSS/easy-rsa-ipsec
А вообще, еcть вот такие продвинутые решения:
pki.fedoraproject.org/wiki/PKI_Main_Page
www.ejbca.org/
И несколько менее продвинутые, но, тем не менее, удобные:
sourceforge.net/projects/xca/
gnomint.sourceforge.net/
pki.fedoraproject.org/wiki/PKI_Main_Page
www.ejbca.org/
И несколько менее продвинутые, но, тем не менее, удобные:
sourceforge.net/projects/xca/
gnomint.sourceforge.net/
Спс за ответ. Понятно, что ничего нормального и готовогг нет.
Fedora скорее всего привязан к дисту.
ejbca — адская смесь, хотя надо пробовать может там все и хорошо.
пслд два выглядят то, что надо. С Gnomit была засада (уже не помню с чем).
В Gnome еще был проект Seahorse, завязан с ключами, но это конечно то же не то, что хотелось бы.
Fedora скорее всего привязан к дисту.
ejbca — адская смесь, хотя надо пробовать может там все и хорошо.
пслд два выглядят то, что надо. С Gnomit была засада (уже не помню с чем).
В Gnome еще был проект Seahorse, завязан с ключами, но это конечно то же не то, что хотелось бы.
tinc vpn как по мне лучше и удобнее openvpn.
Прелестно
Vlanы были придуманы для разграничения broadcast domain, а тут мы их через vpn со всеми вытекающими. Надеюсь тунель на tcp?
Читать. Или аналоги.
www.ciscopress.com/articles/article.asp?p=24101
Vlanы были придуманы для разграничения broadcast domain, а тут мы их через vpn со всеми вытекающими. Надеюсь тунель на tcp?
Читать. Или аналоги.
www.ciscopress.com/articles/article.asp?p=24101
Best Practice — уменьшение размера L2-домена и максимально использовать L3. По меньшей мере следует придерживаться модели local-VLAN, т.е. vlan не должен выходить за пределы одного аксесс-свича и пары дистрибьюшн свичей, а тем более идти по WAN. Более того, сейчас стали выпускать L3 access-свичи, которые позволяют сузить L2-домен до границ access-коммутатора. Вы сделали что-то совершенно противоположное без веских на это оснований. Для разделения трафика по типу, можно использовать политики QOS, т.е. маркировку трафика DCSP. Ваше решение очень плохо масштабируется по очень простой причине — если у Вас будет несколько площадок, с резервированием, как Вы будете решать проблемы с L2- петлями? Запустите STP поверх IP?
А я бы на Cisco в VPN-туннель psewdowire запихал, раз задача такая.
Я думаю лучше всего было бы использовать MPLS, но народ очень активно эту технологию игнорирует и продолжает использовать адские велосипеды.
Вы имеете в виду технологию MPLS-VPN? Во-первых, данная технология не отменяет необходимости шифровать трафик в некоторых ситуациях, т.е. всё теже туннели поверх mpls. Во-вторых, технология не дешёвая. Ну и пожалуй самое важное, MPLS-VPN привязывает Вас к одному или к нескольким провайдерам, между которыми существует mpls-пиринг, что не всегда приемлемо. Если вы имеете множество площадок с очень разнообразной географией и соответственно большое количество разных ISP Вы, скорее всего, не сможете связать их все с помощью mpls-VPN/
Шифровать лучше в любом случаи.
Не дешевая? Хм, что в не дорого? Мы используем ее на mikrotik оборудование.
В общем на хабре уже была статья, повторятся не буду habrahabr.ru/post/169103/
ISP тут роли не играет. Делайте хоть 60 точек и соединяйте.
Просто то, что выше когда начнет разрастаться, будет не очень хорошо.
Я просто в уме прикинуть сколько надо будет сделать телодвижений на те же 60 точек.
Не дешевая? Хм, что в не дорого? Мы используем ее на mikrotik оборудование.
В общем на хабре уже была статья, повторятся не буду habrahabr.ru/post/169103/
ISP тут роли не играет. Делайте хоть 60 точек и соединяйте.
Просто то, что выше когда начнет разрастаться, будет не очень хорошо.
Я просто в уме прикинуть сколько надо будет сделать телодвижений на те же 60 точек.
Минуточку. Задача — есть два удалённых сайта, нужно их объединить. Один узел в Лондоне, второй в Шанхае. Расскажите, как в этом случае их объединить с помощью mpls не привлекая провайдера?
MPLS (если мы не про L3VPN каналы) тут вообще никаким боком, он не конкурирует с шифрованными туннелями, а дополняет их. Но это лишняя сущность, без которой по возможности стоит обойтись.
Может быть автор все таки в 2-3 словах расскажет для чего было творить такие чудеса с тунелями вместо нормальной человеческой маршрутизации?
В данном случае трафик чисто внутренний, который не желательно выпускать в мир. Да и сами сервера с ресурсами не имеют доступа в мир.
прекрасно, но ведь можно все это смаршрутизировать через ipsec тунель (или еще какой-нибудь удобый вам) и не плясать вокруг вланов, не? Получилось бы куда более масштабируемо, да и схема традиционная как никак
С ipsec опыта работы не имел, а с openvpn и open vSwitch сталкивался ранее, поэтому на них всё и организовал.
ну можно было бы смаршрутизировать и через openvpn — тут принципиальной разницы нет. любой удобный протокол динамической маршрутизации решил бы вопрос в считаные минуты (ну или статикой, тогда чуть подольше)
не совсем понятно желание именно тащить вланы, — обычно от этого бегут как от огня, а вы по своей инициативе ;) — вот я ж и уточняю, может были какие-то принципиальные моменты блокирующие решение на основе маршрутизации?
не совсем понятно желание именно тащить вланы, — обычно от этого бегут как от огня, а вы по своей инициативе ;) — вот я ж и уточняю, может были какие-то принципиальные моменты блокирующие решение на основе маршрутизации?
Существует странное китайское оборудование, которому непременно нужно l2 (хотя по идее задача такая, что не должно быть нужно). Был у нас случай — специально к нам обратились, чтобы поверх IP VPN, предоставленный провайдером, сделать L2 VPN, который нужен железкам.
Мы тогда сделали на L2TP. Это было ошибкой, я чуть позже повторил это же самое на OpenVPN — он оказался просто фантастикой по сравнению с L2TP, как в плане масштабируемости, так и в плане надёжности.
Мы тогда сделали на L2TP. Это было ошибкой, я чуть позже повторил это же самое на OpenVPN — он оказался просто фантастикой по сравнению с L2TP, как в плане масштабируемости, так и в плане надёжности.
Хочу узнать, что я упускаю, но в любом дистрибутиве можно поднимать туннели встроенными средствами iproute и iptables (если не ошибаюсь) с помощью двух строчек в конфигах.
Зачем такие сложности городить?
Зачем такие сложности городить?
iproute2 достаточно
тоннели да, но шифрование вы с их помощью не сделаете. Да и «встроенные средства» шифрования в виде ipsec в любом дистрибутиве — те ещё сложности, которые как раз не надо городить, а надо просто брать openvpn и не извращаться
ну да. и бог с ним что не мультивендорно, пускай себе юзерспейс (со всеми накладными расходами), надо просто брать и не извращаться
что делать когда в филиале на место тазика приедет например кошка, и/или когда филиалов станет много и часть трафика будет невыгодно пропускать через центральный офис — это пускай другие думают, наверное…
что делать когда в филиале на место тазика приедет например кошка, и/или когда филиалов станет много и часть трафика будет невыгодно пропускать через центральный офис — это пускай другие думают, наверное…
Сначала делим трафик:
Потом его же пытаемся пробросить куда-то по негарантированным каналам.
Позвольте поинтересоваться: а по вашему тоннелю широковещательный трафик тоже ходит?
При этом внутри корпоративной сети использовалось несколько виртуальных сетей (VLAN) — для телефонии, доступа к базе данных, управления оборудованием и т.п.
Потом его же пытаемся пробросить куда-то по негарантированным каналам.
Позвольте поинтересоваться: а по вашему тоннелю широковещательный трафик тоже ходит?
подозреваю, ради этого все и затевалось
(есть конечно вариант что это решение — первое что пришло в голову, а первая идея не всегда лучшая)
(есть конечно вариант что это решение — первое что пришло в голову, а первая идея не всегда лучшая)
не написано же
>Используется устройство tap для возможности передавать ethernet-кадры.
>Используется устройство tap для возможности передавать ethernet-кадры.
Ходит по таким туннелям широковещательный трафик. Сталкивался я с такими туннелями на предыдущем месте работы. Реализация была такой ввиду коротких сроков и нежелания начальства тратить деньги на организацию физического линка. Иначе было сложно на имеющемся оборудовании выдавать белые адреса клиентам. Сначала кинул вланы через туннель, а потом боролся с паразитным трафиком…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проброс VLAN-ов через интернет