Перейти к содержимому
Калькуляторы

devi11

Пользователи
  • Публикации

    35
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем devi11


  1. У OVPN по определению большой оверхед. Работает он в UserSpace и сильно нагружает CPU. А вообще Saab правильно сказал - нужно правильно тестировать. Если замеряете скорость с тех же устройств, которые занимаются установлением VPN, то их производительность съедает само тестирование. Да и мерить надо в несколько потоков.

  2. видимо, я не так был понят. когда видно, что линк ушел в даун - это и правда просто. я спрашивал о ситуации, когда физика в up, а трафик не бегает.

     

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

  3. Я же писал - поставьте 3 микротика в центре и по 3 в каждом офисе. Все будет отлично и бесперебойно работать.

    Ну а сам механизм VPN как обеспечить? 2 туннеля + OSPF? Или всё-таки бондинг? Или вообще BGP?

  4. 3. Конкретные модели оборудования советовать - нужно знать трафик и кол-во абонентов.

    Если действительно нужна высокая надёжность то с микротиком я бы не связывался уж точно.

    Спасибо!

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

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

    А с этим Saab95 был прав. Буквально сегодня столкнулся с DDoS'ом на один из линков. И маркировка входящих соединений в полочку загрузила процессор, т.к. трафик сначала проходит через Connection Tracking, а потом Mangle Prerouting и входящие коннекты ничем невозможно отсеять. Фактически, роутер не справляется со своими задачами, т.к. проц перегружен.

    Догадываюсь, что сейчас полетят ответы типа "Используйте специальную железку для защиты от DDoS'а стоимостью $100500", но как вы понимаете, не каждый может себе позволить такую роскошь.

  6. абсолютно нисколько, там делов на 5 минут и происходит раз в пятилетку

    Поздравляю Вас!

    Спокойная у вас жизнь.

    А я вот не могу на минуту юзеров лишить интернета и VPN'а, поэтому и прошу отказоустойчивую схему.

  7. Взял любую другую, переткнул винт и оно всё снова работает, ЗИПа просто завались.

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

  8. Например если вам надо подключить 2 провайдера к одному устройству, то придется сделать несколько маркировок, несколько перенаправлений и т.п., все это будет занимать ресурсы.

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

    А можно поставить маршрутизатор помощнее, ресурсы которого маркировка не будет занимать на 100%. Да и не встречал я такого, что маркировка 2-3 100 Mbps каналов на RB1100AHx2 отбирала 20% CPU. А RB1100 далеко не самый мощный в линейке.

  9. MT1 держит связь с первым устройством в центре, MT2 со вторым. MT3 по изолированным подсетям имеет связь с первыми двумя микротиками, а на порту в сторону компьютеров офиса установлена уникальная подсеть /24 например. При этом в каждом офисе подсеть своя и на серверах конторы в центре все потребители видятся по этим адресам.

    Эта схема пока лучшее из всего, что тут наобсуждали.

    MT1, MT2 - VPN-сервера. MT3 - роутер. Вы ведь это имели в виду?

    А если на MT1 и МТ2 не включена OSPF, как МТ3 поймет, что подсеть 192.168.125.0/24 принадлежит филиалу доступна через МТ1, например, а не МТ2?

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

    Отчего ж они "ненужные"? Их для галочки сделали чтоли? Если есть технология, почему бы ей не воспользоваться? А если у вас будет 12 провайдеров, Вы 13 микротиков поставите, вместо одного?

  11. Если вы возьмете 3 устройства (не винда), к одному из них подключите 2, дав каждому свой уникальный адрес, то если создадите 2 (два) маршрута по умолчанию с одинаковыми метриками на разные IP адреса, то работать будет только один.

    Если говорить про указанное вами понятие, то оно имеет несколько другой смысл, когда вы для 1 (одного) дефолтного маршрута указываете 2 шлюза. В этом случае один пакет идет на первый шлюз, второй пакет на второй, третий на первый и так далее.

    Именно по этой причине у вас и наблюдаются косяки.

    Так я вам про винду говорю.

  12. Не ECMP, но все же . А сервера отдают на default gw (1-ый роутер), а тот отдает в туннель свой либо на второй маршрутизатор и тот уже в свой туннель

     

    Да и к чему весь этот спор? Я попросил схемы обеспечения отказоустойчивости, а начался срач про гейты. Если кому интересно могу расписать работу этого узла в подробностях.

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

    Аргументируйте, пожалуйста.

    Вам знакомо понятие Equal Cost Multipath Routing? А работу двух гейтвеев на винде тоже не видели?

  14. А между микротиками и бизнес серверами в центре и микротиками и клиентами в филиалах ещё что есть или VRRP?

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

     

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

  15. В филиалах каким образом настроили, что бы один туннель шел через одного провайдера, а второй через другого?

    /ip route add dst-address=1.2.3.4/32 gw 192.168.0.1

     

    Такого быть не может, из-за этого и не работает.

    Что значит "не может"? Ещё как может и работает

  16. У вас 2 сервера для подключения PPP и каждый подключен к коммутатору, следовательно IP адреса у них разные. Поэтому когда клиент работает через один сервер, то и на все рабочие сервера попадает с него, когда связь по туннелям пропадает, то данные уже бегут через другой IP, т.к. они уже выдаются через второй VPN-сервер.

    У серверов прописано два шлюза по умолчанию.

  17. Не совсем понятна схема.

    Как я понял в центре два микротика и в филиалах по два микротика - так?

    В центрне два, на филиалах один.

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

  18. Люди добрые, расскажите как правильно обеспечивается отказоустойчивость сетей, объединенных через VPN.

    На данный момент имеем такую схему:

    1. Имеется два VPN-сервера (Mikrotik, SSTP) на разных провайдерах.

    2. Эти серверы включены в один коммутатор LAN-портами и оба имеют равнозначный доступ к бизнес-серверам

    3. Каждый филиал поднимает по одному тоннелю к каждому серверу с разных провайдеров.

    4. Отказоустойчивость обеспечивает OSPF. На клиентском роутере (Mikrotik) Cost для одного из VPN-интерфейсов выставлен больше, на одном из серверов для этого интерфейса так же Cost больше, чем на другом сервере до это же филиала.

     

    Проблема в том, что при неполадках провайдеров со стороны филиала или офиса, трафик начинает бежать по другому тоннелю, соответственно рвутся TCP-коннекшены и переподключаются RDP-сессии клиентов.

    Как обеспечить прозрачное для пользователя переключение тоннелей и обеспечить достаточную пропускную способность? Бизнес-трафик: RDP, VoIP, SMB и все, что связано с виндовым доменом.