@RicoX, на моменте запуска процесса asterisk) В момент когда процесс вызывается скриптом safe_asterisk. Если бы мне была нужна помощь эксрасенсов - я бы упомянул это в тексте вопроса.
При запуске через service asterisk start астериск ВСЕГДА валится со стандартной ошибкой Asterisk died with code 1, причем не делает ни одной строчечки логов.
@rostel, права корректные на все.
Запускаю ли я через safe_asterisk, либо после смены пользователя - ВСЕГДА запускается. pastebin.com/CnDBvVrB - modules.conf
@Piranis кто и что обновил утверждать не могу, но, насколько я понимаю, схема такова:
1) @badcluster забирает код с bitbucket на "свою" машину;
2) эта самая машина запускает деплой скрипт;
3) скрипт идет на продакшен сервер и там разворачивает копию.
@SmileyK, несомненно. Если маршрут физически всего один, то, естественно, при падении любого ключевого узла маршрут приходит в негодность. Так, вообще-то, весь интернет работает) Для этого и существует Open Shortest Path First, однако, ему должно быть из чего выбирать) Поэтому, чем больше линков соединяет любые узлы сети - тем лучше для стабильности системы в целом.
А если будет третий офис, то как раз таки вам непременно нужен будет ospf, тогда совершенно не важно каким образом все устройства соединены между собой. У меня сеть из чуть более 50 устройств, объединенных в один большой впн. Когда у меня появляется новое устройство, мне необходимо всего лишь соединить его с ближайшим устройством с помощью любого доступного транспорта и все. Поэтому, не парьтесь по поводу того кто будет сервером, а кто клиентом.
Никаких официальных подтверждений тому, что это ограничение RouterOS я не видел, но запустить два ovpn между двумя микротиками у меня не выходило ни разу. Однако в 6.х версиях я это уже и не пробовал, возможно что-то поменялось.
Если ISP 2 находится за натом провайдера, то Вы в любом случае не сможете поднять на него тоннель.
Исходя из того, что остальные три адреса - постоянные белые адреса, возможно решить вопрос так. Поднимаем два тоннеля:
ISP2 Client => ISP4 Server
ISP1 Server <= ISP3 Client
А уже поверх, чтобы не париться с маршрутами, проще всего (строго говоря "правильнее всего") поднять OSPF, чтобы забыть об этой проблеме. Ну или статикой разрулить как нужно.
Два правила, одно из которых с отрицанием - излишни!
/ip firewall filter add chain=forward in-inteface=wan1 out-interface=eth1 action=drop
решает поставленную задачу полностью. Включив это правило, вы будете блокировать все пакеты, пришедшие из интерфейса локальной сети и направляющиеся в интернет. Проверять любые другие условия не нужно, если я правильно понял суть проблемы.
Конечно соединение висит до таймаута, это же суть протокола. Есть вот такая штука: /ip firewall connection tracking. Она как раз и занимается отслеживанием открытых соединений. Можно ее отключить полностью, либо уменьшить параметр tcp-established-timeout, который по умолчанию равен 1d, т.е. те самые сутки. Однако имейте ввиду, что при полном отключении многие разделы firewall вообще перестанут работать: mangle, например и многие правила фильтра.
