devi11
-
Публикации
35 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем devi11
-
-
У OVPN по определению большой оверхед. Работает он в UserSpace и сильно нагружает CPU. А вообще Saab правильно сказал - нужно правильно тестировать. Если замеряете скорость с тех же устройств, которые занимаются установлением VPN, то их производительность съедает само тестирование. Да и мерить надо в несколько потоков.
-
видимо, я не так был понят. когда видно, что линк ушел в даун - это и правда просто. я спрашивал о ситуации, когда физика в up, а трафик не бегает.
Вот от этого и хочется избавиться. Потому что железка никак не понимает, что трафика нет, если тунель поднят - значит все работает, а юзеры плачут, так как их критерии работоспособности не включают в себя понятие туннеля.
-
А как часто это происходит?
Со стороны филиалов постоянно (несколько раз в неделю), со стороны офиса довольно редко.
-
2 туннеля L2TP
Почему именно L2TP?
-
вы просто не умеете netfilter. вот и всё.
Расскажете как им пользоваться? Про PacketFlow в микротике я написал выше.
-
Я же писал - поставьте 3 микротика в центре и по 3 в каждом офисе. Все будет отлично и бесперебойно работать.
Ну а сам механизм VPN как обеспечить? 2 туннеля + OSPF? Или всё-таки бондинг? Или вообще BGP?
-
3. Конкретные модели оборудования советовать - нужно знать трафик и кол-во абонентов.
Если действительно нужна высокая надёжность то с микротиком я бы не связывался уж точно.
Спасибо!
Я и не прошу конкретные модели оборудования. Мне хотелось узнать варианты обеспечения отказоустойчивости и выбрать из них наиболее приемлемый для меня. Хотя микротик в соотношении цена/возможности пока выигрывает. Мне не нужны какие-то сверхкрутые функции. Нужно просто поднять несколько сотен туннелей, настроить маршрутизацию/приоритезацию и обеспечить приемлемую скорость в каждом туннеле.
-
На ней видно, что для приема каждого канала стоит отдельная железка, потом на другой железке все сводится, а сервера решают каждый свою задачу.
А с этим Saab95 был прав. Буквально сегодня столкнулся с DDoS'ом на один из линков. И маркировка входящих соединений в полочку загрузила процессор, т.к. трафик сначала проходит через Connection Tracking, а потом Mangle Prerouting и входящие коннекты ничем невозможно отсеять. Фактически, роутер не справляется со своими задачами, т.к. проц перегружен.
Догадываюсь, что сейчас полетят ответы типа "Используйте специальную железку для защиты от DDoS'а стоимостью $100500", но как вы понимаете, не каждый может себе позволить такую роскошь.
-
абсолютно нисколько, там делов на 5 минут и происходит раз в пятилетку
Поздравляю Вас!
Спокойная у вас жизнь.
А я вот не могу на минуту юзеров лишить интернета и VPN'а, поэтому и прошу отказоустойчивую схему.
-
Взял любую другую, переткнул винт и оно всё снова работает, ЗИПа просто завались.
Не думаю, что это входит в понятие отказоустойчивости. Пока вы перетыкаете винт, сколько клиентов от вас уйдут?
-
Опубликовано · Изменено пользователем devi11 · Жалоба на ответ
Например если вам надо подключить 2 провайдера к одному устройству, то придется сделать несколько маркировок, несколько перенаправлений и т.п., все это будет занимать ресурсы.
Можно поставить 3 микротика, при этом каждый из них будет делать только простую работу, что позволит передавать в разы больше трафика.
А можно поставить маршрутизатор помощнее, ресурсы которого маркировка не будет занимать на 100%. Да и не встречал я такого, что маркировка 2-3 100 Mbps каналов на RB1100AHx2 отбирала 20% CPU. А RB1100 далеко не самый мощный в линейке.
-
MT1 держит связь с первым устройством в центре, MT2 со вторым. MT3 по изолированным подсетям имеет связь с первыми двумя микротиками, а на порту в сторону компьютеров офиса установлена уникальная подсеть /24 например. При этом в каждом офисе подсеть своя и на серверах конторы в центре все потребители видятся по этим адресам.
Эта схема пока лучшее из всего, что тут наобсуждали.
MT1, MT2 - VPN-сервера. MT3 - роутер. Вы ведь это имели в виду?
А если на MT1 и МТ2 не включена OSPF, как МТ3 поймет, что подсеть 192.168.125.0/24 принадлежит филиалу доступна через МТ1, например, а не МТ2?
-
Просто так на одном устройстве нельзя сделать что бы данные по каждому провайдеру уходили через свои каналы, нужно прибегать к маркировкам и прочим не нужным вещам.
Отчего ж они "ненужные"? Их для галочки сделали чтоли? Если есть технология, почему бы ей не воспользоваться? А если у вас будет 12 провайдеров, Вы 13 микротиков поставите, вместо одного?
-
Я приложил картинку как надо делать правильно:
А я не понимаю, зачем нужен MT3 в офисе. Между MT1/MT2 и MT3 изолированная сеть?
-
Если вы возьмете 3 устройства (не винда), к одному из них подключите 2, дав каждому свой уникальный адрес, то если создадите 2 (два) маршрута по умолчанию с одинаковыми метриками на разные IP адреса, то работать будет только один.
Если говорить про указанное вами понятие, то оно имеет несколько другой смысл, когда вы для 1 (одного) дефолтного маршрута указываете 2 шлюза. В этом случае один пакет идет на первый шлюз, второй пакет на второй, третий на первый и так далее.
Именно по этой причине у вас и наблюдаются косяки.
Так я вам про винду говорю.
-
Не ECMP, но все же . А сервера отдают на default gw (1-ый роутер), а тот отдает в туннель свой либо на второй маршрутизатор и тот уже в свой туннель
Да и к чему весь этот спор? Я попросил схемы обеспечения отказоустойчивости, а начался срач про гейты. Если кому интересно могу расписать работу этого узла в подробностях.
-
То и значит, что не может. Дефолтный маршрут может быть только один. Вам надо либо завязать центральное оборудование с микротиком тоже по OSPF, либо поставить третий микротик, либо из имеющихся двух выбрать один, а от второго отключить кабель в сторону вашей внутренней сети, соединив их между собой непосредственно через свободные порты. Тогда ваше оборудование внутри сети будет общаться только с одним микротиком.
Аргументируйте, пожалуйста.
Вам знакомо понятие Equal Cost Multipath Routing? А работу двух гейтвеев на винде тоже не видели?
-
Отдают на дефолт гейтвей, а тот решает, куда пакету идти дальше. Не вижу здесь ничего страшного.
-
А между микротиками и бизнес серверами в центре и микротиками и клиентами в филиалах ещё что есть или VRRP?
Ничего нет. Только сеть провайдера. VRRP не используем, но мысли о нем думаем.
Я хотел бы ещё раз уточнить, что тут я не прошу критики своей сети. Я хотел бы узнать как "оно делается правильно". Собранные шишки с несколькими туннелями и OSPF показывают, что моя схема неверная. Нужно как-то балансировать туннели, судя по всему. Вот я и хочу послушать от опытных людей, как они это делают.
-
В филиалах каким образом настроили, что бы один туннель шел через одного провайдера, а второй через другого?
/ip route add dst-address=1.2.3.4/32 gw 192.168.0.1
Такого быть не может, из-за этого и не работает.
Что значит "не может"? Ещё как может и работает
-
У вас 2 сервера для подключения PPP и каждый подключен к коммутатору, следовательно IP адреса у них разные. Поэтому когда клиент работает через один сервер, то и на все рабочие сервера попадает с него, когда связь по туннелям пропадает, то данные уже бегут через другой IP, т.к. они уже выдаются через второй VPN-сервер.
У серверов прописано два шлюза по умолчанию.
-
Не совсем понятна схема.
Как я понял в центре два микротика и в филиалах по два микротика - так?
В центрне два, на филиалах один.
Тут вопрос не столько про оптимизацию моей схемы, сколько про то, как делается "правильно". Была мысль строить два тоннеля из филиала до центра и делать бондинг между этими тоннелями. Или ещё какой вариант.
-
уже противоречия
На оборудование не завязан. По существу что-нибудь скажете?
-
Люди добрые, расскажите как правильно обеспечивается отказоустойчивость сетей, объединенных через VPN.
На данный момент имеем такую схему:
1. Имеется два VPN-сервера (Mikrotik, SSTP) на разных провайдерах.
2. Эти серверы включены в один коммутатор LAN-портами и оба имеют равнозначный доступ к бизнес-серверам
3. Каждый филиал поднимает по одному тоннелю к каждому серверу с разных провайдеров.
4. Отказоустойчивость обеспечивает OSPF. На клиентском роутере (Mikrotik) Cost для одного из VPN-интерфейсов выставлен больше, на одном из серверов для этого интерфейса так же Cost больше, чем на другом сервере до это же филиала.
Проблема в том, что при неполадках провайдеров со стороны филиала или офиса, трафик начинает бежать по другому тоннелю, соответственно рвутся TCP-коннекшены и переподключаются RDP-сессии клиентов.
Как обеспечить прозрачное для пользователя переключение тоннелей и обеспечить достаточную пропускную способность? Бизнес-трафик: RDP, VoIP, SMB и все, что связано с виндовым доменом.
Mikrotik - 2 dhcp сервера отказоустойчивость
в Mikrotik коммутаторы и маршрутизаторы
Опубликовано · Изменено пользователем devi11 · Жалоба на ответ
Поигрался со скриптами и конфигурацией сервера. Описал процесс у себя в блоге