Jump to content
Калькуляторы

devi11

Пользователи
  • Posts

    35
  • Joined

  • Last visited

Everything posted by devi11


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