Pull to refresh

Comments 31

Один заказчик, два помещения, четыре провайдера и восемь связей
… и три копии статьи на хабре
Повторение — мать учения!
не посмотрел. Наверное очень популярная тема. Только эту статью писал не по чужим. Вряд ли это копии…
Первый комментарий запечатлел краткий миг истории, когда в результате технического сбоя статья была опубликована трижды. Конечно, сейчас дубли удалены. Никаких намеков на плагиат.
Если не трудно — киньте ссылки. Сразу так и не нашёл.
maovrn, имел виду то что вы опубликовали эту статью три раза подряд. (судя по тому что счетчик публикаций в вашем профиле равен единице — дубли удалил модератор — а вы и не заметили как это произошло ;))
bgduikneb789o3krjhgt98728550

Мне показалось, или действительно пахнет дымом?
Чем netwatch не устраивает? им и переключать активный канал и в итоге не надо городить гору тоннелей с интерфейсами.

Плюс команду атске можно через fetch кинуть из netwatch, что активный канал сменился, хотя с тем же астериском правильней вписать домен в externhost и через DNS обновлять запись.

ps Астериск прекрасно живет внутри микротиков с поддержкой metarouter\kvm
netwatch не заработал, вернее не так. Поработал и перестал. Почему — не стал разбираться.
Открыл статью как раз чтобы узнать, на какой технологии VPN сделано здесь, и _почему_. Увы. Прочел:

> Организация VPN-соединений
>
> Для организации VPN-соединений решено использовать протокол IPSec и IPIP-туннели. Составим таблички для туннелей

Скажите, а почему IPSec, а не, скажем, ovpn или sstp? «С потолка», или «выстрадано»? В последнем случае расскажите, это, честное слово, будет куда интереснее очередного рассказа про «два впн-а на нос».
Потому, что в IPIP есть такая фича — IPSec пароль. Туннель сам генерит политику. Сделано просто для облегчения конфигурации. Напишите статью про ovpn или sstp — если будет проще, с удовольствием буду применять. :)
UFO just landed and posted this here
Вам осталось улучшить ваше решение следующим образом:
1) Установить по два микротика на каждом объекте (ведь отказать может не только провайдер, но и маршрутизатор).
2) Настроить маршрутизацию между сетями через ospf.
3) Настроить шлюз в каждой сети через VRRP и сделать переключение VRRP через watchdog в случае падения канала Интернет на основном маршрутизаторе.
И еще сменить адресацию в офисе со 192.168.1.0/24 на неиспользуемую домашними роутерами, а то через VPN домашние пользователи у вас работать могут через раз.
У меня самого огород из кучи офисов с микротиками из младших и старших линеек.
1) Возможно в центральных офисах и имеет смысл vrrp и еще один CCR от микротика, но финансовая составляющая подсказывает что лучше держать просто одну железку в резерве, и в случае чего ее заменять накатив бекап конфига.
2) ospf это интересно конечно, но в двух офисах можно и руками прописать маршруты, плюс ospf при перестройке маршрутов негативно накладываться на проходящий внутри голосовой трафик, в отличии от маршрутов с метрикой.
3) пункт 1

1) Возможно в центральных офисах и имеет смысл vrrp и еще один CCR от микротика, но финансовая составляющая подсказывает что лучше держать просто одну железку в резерве, и в случае чего ее заменять накатив бекап конфига.

Если вы купили второй канал Интернет, то по сравнению с ним стоимость микротика — копейки. Ну и держать роутер в резерве и в случае чего ехать на объект, чтобы его заменить, сводить на нет всю идею обеспечения отказоустойчивости.

2) ospf это интересно конечно, но в двух офисах можно и руками прописать маршруты, плюс ospf при перестройке маршрутов негативно накладываться на проходящий внутри голосовой трафик, в отличии от маршрутов с метрикой.

Как он негативно накладывается на голосовой трафик? Объясните механизм плз.
1) два гигабитных канала по 15к, CCR микротик от штуки баксов, офисов овер дофига. Выгодней купить один запасной на несколько офисов и пусть валяется на складе. За все время работы только мерли обычные свитчи тупые.
2) При перестроении маршрутов происходит залипание на долю секунды, при разговоре это вываливается в проглатывании слов. UDP такой UDP.
1) два гигабитных канала по 15к, CCR микротик от штуки баксов, офисов овер дофига. Выгодней купить один запасной на несколько офисов и пусть валяется на складе. За все время работы только мерли обычные свитчи тупые.

Судя по всему, вы покупаете оборудование по принципу «чем дороже — тем лучше». Использовать CCR для подключения пары провайдеров и организации IPSec — огромная глупость. Денег много, а скорость VPN ниже.

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

И у микротика нет среднего решения, либо слабое железо, либо 36 ядерный монстр. Единственно среднее, это собирать самому на x86 и туда вкатывать лицензию.

Зря вы чтото там про комментировать, в практике случалось что ложились все провайдеры в очень отдаленных офисах, изза того что все «оба» прова имеют общую будку коммутации до которой просто физически рвалась оптика. И тут никакой vrrp бы из двух роутеров бы не помог.

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


У вас эксклюзивные гигабитные каналы. За 15 000 р./месяц на складе в среднем можно получить 5-10 Мбит скорости. Гигабит юрлицам в офисах за такие деньги никто не подключает, да и скорости такие не ИТ-компаниям не нужны.

Без шифрования гигабитную нагрузку выдерживает RB2011UiAS-IN (119$), с шифрованием AES он же тянет порядка 20-30 Мбит/с, чего хватает для подключения 4-5 офисов с 40-50 пользователями в них.

Когда штраф за задержку фуры на складе составляет тысячи рублей в час, купить второй маршрутизатор за 119$ не составляет проблем.

Все можно, с руководством провайдеров дружить нужно, не все жадные и занудные.

По ночам сливать базы с бекапами, samba и прочее. 20-30 мегабит тут никак не зайдёт, плюс надо еще приоритеты при этом нормально отрабатывали. Так же по l2tp люди цепляются и комуто и скорости под rdp хватит, а какому нибудь 1cнику надо максимально возможную полосу, чтобы слить\залить конфу или базу.

Изначально делал маршрутизацию на ospf, но он передергивал маршруты постоянно как по таймауту причем на те же самые при нормально рабочих каналах, заметил это только из-за того что народ жаловаться начал что иногда телефоны лагают, т.к. кол-во офисов перестало расти, то через «ssh_all» нарисовал везде маршруты с метриками и убрал в дальний ящик эту проблему.
Поддерживаю идею не ездить. Если критично — можно махонькую железку купить, сливать туда бэкап и ответственному работнику написать инструкцию. ;)
Как вариант, но этот вариант был выбран как бюджетное решение. И к тому же очень простое. И к тому же работающее. Ваши варианты конечно же будут работать. Но в условиях Заказчика проводить доп.работы по ospf и т.д. просто не было денег и времени. ;)
Вы можете пояснить как работает правило:
/ip firewall nat
add chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.2.0/24

Ведь нет же действия. Не понятно на что SNAT-ить. Как MikroTik действует в этой ситуации?
как и в iptables проходит соединение без маскарадинга и прочих подмен, прямое обращение между сетями
Действия нет. NAT-ить не надо! Для перемещения пакетов в корпоративной среде NAT не нужен. Нужна простая маршрутизация.
Ааааааа! NAT сработает раньше чем пакет завернётся в туннель!
То есть это аналог:
iptables -I POSTROUTING -t nat -d АДРЕС_УДАЛЕННОЙ_ПОДСЕТИ -j RETURN

Не знаю. iptables не использую. Пользовался ipfw. А при чём здесь аналог?
Может потому что микротиковский фаервол на netfilter как и iptables
Да. Только в MikroTik-е похоже не используется iptables, а используется какой-то свой способ взаимодействовать с netfilter.

Любопытно, что в MikroTik-е есть действие RETURN, но вы этот момент обходите с помощью вышеупомянутого:
/ip firewall nat
add chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.2.0/24

Это получается фича MikroTik-а.
Sign up to leave a comment.

Articles