Pull to refresh

Comments 71

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

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

ансибл имеет вполне внятную обработку ошибок — это раз, два — у него вменяемые логи выполнения. Поэтому — да, я согласен с osipov_dv
и, да — фтп не нужен, по идее достаточно API доступа.

Научить ямлики, что они на пол пути потеряли половину команд по SSH из-за LTE (2 из 10 команд долетело)- это не ошибка будет.

Вы сейчас шутите? По-моему, Вы просто не разобрались как это работает.
И, да, как будет обеспечиваться дозагрузка файлов по фтп? Если Коннект нестабильный, то он нестабильный вне зависимости от протокола...

В конкретном рассматриваемом случае не достаточно ли с помощью того же ansible (routeros_command) посмотреть вывод "/interface ovpn-client print"? Если интерфейс поднялся — значит, всё прошло успешно, нет — тогда уже разбираемся, что конкретно не так.
Если 4 или 10 изменений за раз? это уже 400 или 1000 строк лога. А так 1 файл с «Script file loaded and executed successfully». Плюс фишка auto.rsc. если конфиг который отправили с ошибкой, то весь скрипт откатиться и даст лог(не вкрячится в состоянии полтора). Там очень много тонкостей.

Этот же файл можно скормить ansible. К тому же, если у вас один универсальный конфиг, за исключением сетевых настроек, то почему вы ожидаете разную реакцию на разных устройствах?

auto.rsc работает исключительно по FTP. Разные конфигурации устройств, разная версия RouterOS и тд и тп…
sudo chmod +x newsh1.sh
sudo ./newsh1.sh

Не сидите под рутом, говорили они, отключайте рута на ссш, говорили они…

Согласен. А вместо портянок на баше пишется шаблон на jinja2 и потом к нему применяется шаблонизатор с параметрами. Плюсы — даже не специалист разберётся что там поправить, нет уродливых и ненадежных конструкций с sed/awk, можно обойтись без промежуточных файлов (если кормить выхлоп шаблонизатора через пайп куда угодно). Минусы — надо ставить jinja в систему, но, внезапно, она там обычно есть, вместе с интерпретатором python


А ещё для пакетной загрузки файлов по фтп except не нужен.


Уважаемые, коллеги-сетевики! Вместо того, чтобы рожать кадавров — посмотрите вокруг и поспрашивайте знакомых, программистов — как можно решить задачу красивее, эффективнее, надёжнее

нет уродливых и ненадежных конструкций с sed/awk

ммм, как-то вы радикально…
пару десятков лет работают скрипты и ничего не глючит

То что написано — переписывать уже не нужно. Это наше достояние, наследие )


Но новое — лучше писать на надежном, простом фундаменте. Забор из sed/awk'а в принципе нечитаем, неудобно его поддерживать, а еще нужно понимать, что многие не умеют в один проход подставить значения. Нужно еще держать в голове — in-place редактирование файла или нет. Сложную шаблонизацию на них (с циклами, всякими хитрыми подстановками и пр.) в принципе сделать очень больно. Но… Каждому свое )


Единственный плюс у sed/awk в том, что это проверенные временем мощные утилиты, которые есть почти везде. Но на этом преимущества и заканчиваются.

Комментировать код и использовать форматирование вы пробовали?

Если речь дошла до автоматизации, почему выбран microtik, а не cisco?
Сколько неговорил с сетеваками один негатив от микротика

UFO just landed and posted this here
  1. Какая связь между автоматизацией и выбором типа оборудования?
  2. По соотношению цена/качество микротик лучше виски. Да, продукт со своими недостатками. Но задачи выполняет и обходится существенно дешевле. Кому-то нужно 99.99999% и там свои решения, кому-то достаточно 99.99% или даже 99.9% и там микротик уже ничем не хуже.

p.s. А есть ещё отличная шутка, когда стоит железа на дохриллион долларов, резервные каналы, отдельные вводы и всё такое, дублирующие дизеля,… а потом пара экскаваторов одновременно на удалении в километр+ от датацентра умудряются порвать и основную и резервную оптику, а возможно сразу и резерв резерва порвут… ;)

Как в целом большая сеть устройств микротика на LTE? Какие дополнительные инструменты используете для управления и мониторинга?
Работает нормально.
Netwatch — очень облегчает жизнь, если модем подвисает то ребутает его скриптом(netwatch функционал Mikrotika). Мониторинг Zabbix написано очень много для него шаблонов.
А вот кстати, не поделитесь статистикой?
У меня Микротик с LTE (SXT LTE Kit) ровно один :) И всё не могу понять — 3-4 подвисания LTE-интерфейса в сутки (тем самым netwatch по пропаданию пинга до 1.1.1.1 дёргается скрипт, который делает /interface lte disable lte1, потом /interface lte enable lte1 и шлёт отчёт о содеянном на почту, — ребутать дольше) — это для него нормально? Смотрит в упор на вышку в 650 метрах прямой видимости от себя, так что это не проблемы с качеством сигнала. Или это уже проблема с железом?
И всё не могу понять — 3-4 подвисания LTE-интерфейса в сутки (тем самым netwatch по пропаданию пинга до 1.1.1.1 дёргается скрипт.

Какой-то топорный подход. В корне неправильный. Это же беспроводная связь. Потери пакетов там — это нормальная ситуация, а вы, зачем-то, интерфейс перевключаете по этому событию. Какой в этом принципиальный смысл? Он сам заработает, если ему не мешать.
В том-то и дело, что не заработает — там не просто пакеты теряются, а именно что подвисает интерфейс, пока его не рестартануть (или весь девайс не ребутнуть).

Собственно, я и начал решать проблему именно обнаружив, что связи с модемом по LTE нет уже пару дней (канал резервный, нужен раз в месяц, отдельно его не мониторил — а тут отвалился основной, а раз — резервного-то тоже нет). Ребутнул — связь появилась тут же. Сначала поставил watchdog, который тупо делает ребут, потом поменял на netwatch, который дёргает кастомный скрипт и рестарт интерфейса без ребута.

У netwatch задаётся интервал, в течение которого он пытается достучаться до хоста, прежде чем сделать вывод о его недоступности. Если ставить 5 секунд и более — то это уже точно не обычные потери.
Вдумайтесь, вы перевключаете интерфейс при пропуске 3 ответов ICMP.

Если городить такой огород, то уж лучше по событию registration-status: !registered

А ещё лучше обновиться до последней stable.
И обновить модем
/interface lte firmware-upgrade lte1 upgrade=yes

Думаю все проблемы и так уйдут.
За подсказку про обновление модема (RouterOS и так последняя) спасибо, не знал. Обновил, на одну ревизию новее прошивка стала (MikroTik_CP_2.160.000_v013 вместо MikroTik_CP_2.160.000_v012).

registration-status, что характерно, при большинстве таких зависаний остаётся registered, и лишь изредка unknown. Но мысль понял, позаписываю вывод "/interface lte info lte1 once" до/после возникновения проблем, попробую поймать, что конкретно является корректным признаком ситуации «вот сейчас точно зависли»

P.S. Я не настоящий микротикщик :), эту железку взял просто потому, что в таком форм-факторе и ценовом диапазоне выбора не было. И вот на её примере первый раз в жизни Mikrotik осваиваю. И сильно ругаюсь после Ubiquiti :)
registration-status, что характерно, при большинстве таких зависаний остаётся registered

Я и не удивлен, потому что если модем остается подключен, то он сам заработает, когда оператор восстановит транзит или связь чуть улучшится. Последите тогда ещё за functionality: full

И на заметку, если модем реально подвис, то переключение интерфейса ему не поможет, нужно снимать питание:

/system routerboard usb power-reset duration=10

В вашем случае самое простое это, если уж так хочется использовать netwatch, то делайте проверку после status: down на netwarch, что functionality: !full и registration-status: !registered. И желательно секунд 20-30 спустя. Так как если связь сразу восстановится вы не получаете около минутный перерыв связи на включение и выключение, поиск оператора и регистрацию.
Спасибо, буду анализировать, что оно у меня там в разных ситуациях пишет!
Пока ситуация и так устраивала, ибо канал сугубо резервный и шансы, что проблемы с основным каналом и зависание LTE на этом модеме совпадут по времени, крайне невысоки. Главное, чтобы он не зависал надолго и не оказался недоступен ни с какой стороны как раз в тот момент, когда понадобится.
Но перфекционизма ради, безусловно, хочется разобраться окончательно и сделать всё правильно.
А ещё лучше обновиться до последней stable.


Stable уже не совсем stable. Они в какой то момент всё передвинули и сейчас лучше сидеть на — long-term.
Это очень спорный вопрос. Да, меньше шансов нарваться на баг. Но эти случаи очень редки. Новые функции приходится ждать невыносимо долго, а то и вообще не дождаться. Хотя если они не нужны, то может это и не проблема.

Я придерживаюсь следующей стратегии, при выходе новой минорной версии на stable дождаться х.х.1, тогда проблем точно не будет.

Один раз, по совету саппорта микротика, пришлось мигрировать на «testing», в связи с проблемами с только что разработанным железом, и долго на ней работал и то ничего не случилось.
Если мониторить по большей части именно Микротики, то можно поставить Dude от них же. И тогда можно хоть удалённые обновления централизованно накатывать.

Зачем выбрали OpenVPN? Да ещё over TCP (ибо поверх UDP ovpn в микротике не поддерживается). Работать, конечно, будет, но на плохом соединении (как вы сами и писали) инкапсуляция в TCP начнёт совсем всё портить, а вы до кучи рискуете ещё и что-то типа tcp retransmit storm получить, когда из-за потери одного tcp пакета туннеля у вас начнут тормозить и слать горы ретрансмитов все tcp сессии внутри тоннеля.


p.s. Да, знаю про 7ю версию с ovpn over udp, но она ещё не production-ready.

Не автор поста, но мнение имею. На LTE имеются неоднократные случаи блокировок стандартных впн, то IPSec внезапно отвалится, то pptp на пару с l2tp одновременно.

А как это относится к вопросу OpenVPN: UDP vs TCP?
Просто если так рассуждать, то надо вообще SSTP поднимать )

С каких пор SSTP поддерживает udp?

В RouterOS всего два тунельных клиент-серверных протокола, позволяющих задать порт вручную, чтобы обойти блокируемый номер порта на транзите. Другие типы VPN из набора, либо не позволяют поменять порт, либо не позволяют подключатся без двух реальных адресов на концах.

Это SSTP(TCP) и OpenVPN(TCP).

Так вот SSTP не прокачивает больше 11 Mbit/s на ходовых однопроцессорных моделях и его работа упирается куда-то ещё, кроме как в работу процессора. Куда? Непонятно. OpenVPN не то чтобы далеко ушел, но 20 Mbit/s можно выжать.

К слову из-за userspace OpenVPN может грузить только дно ядро, если их больше одного.

Я SSTP упомянул не в ключе UDP, а в ключе "маскировать трафик под легитимный, например, https"
Касательно OpenVPN TCP — tcp amplification/pollution или как оно там называется — я в курсе.


Другие типы VPN из набора, либо не позволяют поменять порт, либо не позволяют подключатся без двух реальных адресов на концах.

Насчет микротика не в курсе, но, во-первых, как минимум, нужен реальный адрес на одном конце (например, IPSec — легко). А вообще — можно туннель и с двумя "серыми" адресами, но там начинаются пляски со всякой дичью типа STUN, т.е. работает будет… далеко не всегда и будет зависимость от фаз луны и положения марса )


не прокачивает больше 11 Mbit/s на ходовых однопроцессорных моделях и его работа упирается куда-то ещё, кроме как в работу процессора

А часто ли ходовые однопроцессорные модели стоят на канале > 100MBit, а по факту даже — 5-10MBit, учитывая, что для юриков интернет весьма дорогой?

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

А вообще — можно туннель и с двумя «серыми» адресами, но там начинаются пляски со всякой дичью типа STUN, т.е. работает будет… далеко не всегда и будет зависимость от фаз луны и положения марса )

Есть только единственный вариант, где заработает схема с двумя серыми адресами на концах. Это когда оператор NAT`ит один к одному, серый в белый. И трансляции отрываются как со стороны интернет, так и с внутренней стороны. Это уже не является, образно, серой адресацией, т.к. по факту это обычный реальник. В этом случае будет достаточно воспользоваться встроенным /ip cloud, который среди прочего является ddns клиентом. И по этому доменному имени подключаться. Будет работать без проблем, без всяких бубнов.

А часто ли ходовые однопроцессорные модели стоят на канале > 100MBit, а по факту даже — 5-10MBit, учитывая, что для юриков интернет весьма дорогой?

Я бы не мешал в одну кучу LTE, с которого началось обсуждение, где совсем другие задачи и каналы не "> 100MBit". И юридических лиц, где реальник и скорости лишь проблема тарификации. В первом случае безраздельно властвует OpenVPN. Во втором случае лучше IPsec ещё ничего не придумали. В большом количестве микротиков есть аппаратная поддержка шифрования. Там можно нагрузить и очень широкие каналы. Гигабит — не предел.

Ну, в общем-то я с Вами и не спорю.


Во втором случае лучше IPsec ещё ничего не придумали.

люто и бешено плюсую. А если еще учесть, что из IPsec можно надергать только то, что нужно конкретному заказчику и то, что это по сути стандартная технология для связи всех энтерпрайз железок… то вообще пушка.

UFO just landed and posted this here
Ну почему?
FTP оно говно мамонта конечно, но рядом с микротиком выглядит вполне гармонично.
Опять же, со слов автора (я не умею в микроты), применять команды из загруженонго конфига можно только при загрузке этого конфига по FTP. Хотя мне кажется что scp/sftp тоже вполне сгодятся, но я не копенгаген, да.

А вот что удивляет в 2019, так это использование expect
мне кажется вся та простыня в newsh2.sh (названия скриптов отдельно умиляет) прекрасно заменяется одной строчкой типа:
curl -T config1.txt ftp://microtik1 --user=user:pssw -sS || 2>mikrotik1.err


Хотя конкретно для этой задачи уместней ансибл. Правда с ансиблом так
пару десятков лет работают скрипты и ничего не глючит
не получится.
Оно слишком быро развивается и многие параметры уходят в deprecated. И зависимость от переменных окружения дикая.
С expect тоже не получится. Не обманывайте себя. Любой скринскрэйпинг — зло. Нельзя на нем автоматизацию строить
Ansible не подходит, потому что можно роутер в состоянии полтора загнать. Половина команд выполнилась, половина с ошибками не выполнилась из за разных версий ПО и оборудования. А конфиг по FTP с расширением auto.rsc. нужен для того чтобы если в конфиге есть ошибка, Mikrotik откинет все изменения которые были в файле сам, так еще и лог даст в файле.
curl -T config1.txt microtik1 --user=user:pssw -sS || 2>mikrotik1.err
Спасибо буду знать.
Где FTP? Не вижу. Вижу SFTP в ссылке и SCP. В документации Mikrotik auto.rsc поддерживает FTP.
В RouterOS можно автоматически выполнять скрипты (ваш файл скрипта должен иметь вид- имя.auto.rsc). После того, как файл будет загружен с помощью FTP на маршрутизатор, он будет автоматически выполнен, как и с командой '/import' (этот метод работает только с FTP).
Ну я, надеюсь, для Вас не составит труда обойти это ограничение?
Опять же, повторюсь, с микротиками не знаком, пожтому не сильно минусуйте есличто, но что мешает выполнить ваш скрипт после загрузки на устройстве отдельной командой:
/import file-name=имя.auto.rsc

ну т.е. ансибл сценарий грубо такой:

 tasks:
    - name: config upload
      net_put:
        src: {{ cfg_filename }}
        protocol: sftp
    - name: apply config
      routeros_command:
        commands: /import {{ cfg_filename }}
И файла имя.auto.log вы не получите с тем что у вас проблема или все хорошо отработало.
Да что ж ты такой деревянный?
 - name: apply config
      routeros_command:
        commands: /import {{ cfg_filename }}
      register: res
 - name: log errors
      debug: var=res.stderr

Ftp по умолчанию не безопасен. Пароль перехватить — раз-два.
Может sftp или ftps, всё-таки ?

Все идет через ovpn канал с сертификатами ид и тп. И я бы с радостью но увы не поддерживает auto.rsc ничего кроме FTP.

Ага. Вы же сами пишете, что мутили весь этот огород, чтобы настроить на микротиках овпн.


оздать сотни конфигов для Mikrotik, чтобы поднять на каждом ovpn с сертификатом

типичная проблема курицы и яйца. Как залить файл по FTP безопасно, если VPN еще нет.

Поведение ansible можно закодировать на основании полученных данных о версии ПО и оборудования (модуль routeros_facts)
UFO just landed and posted this here
В RouterOS можно автоматически выполнять скрипты (ваш файл скрипта должен иметь вид- имя.auto.rsc). После того, как файл будет загружен с помощью FTP на маршрутизатор, он будет автоматически выполнен, как и с командой '/import' (этот метод работает только с FTP).
Как только файл загружен, он автоматически выполняется. Информация об успешности выполнения команд записывается в имя.auto.log
Моя не знать как вам еще объяснить.
FTP небезопасный в конце концов.
А если все в ovpn завернуто с сертификатами? Или вы в серьезе думаете по FTP в интернете кидать это?
UFO just landed and posted this here
каким образом все завернуто в ovpn? Согласно статье вы его только настраиваете?!
Да, проверил, подтверждаю. При upload`е по scp и sftp скрипт не запускается автоматически на последнем stable.
UFO just landed and posted this here
Это не используется для 1 Mikrotik, их ЛЕГИОН, в каждый заходить и проверять по 10 изменений. А тут сразу файлик с логом.

Автоматизация затем и нужна, чтобы не проверять руками изменения… А если изменения проверяются автоматикой, то там же можно сделать роллбек и прочие интересные штуки. Ваша позиция непонятна.

UFO just landed and posted this here

Баг-репорт, надеюсь, отправили ?

Automatic Import

In RouterOS it is possible to automatically execute scripts — your script file has to be named anything.auto.rsc — once this file is uploaded using FTP to the router, it will automatically be executed, just like with the '/import' command. This method only works with FTP.

Once the file is uploaded, it is automatically executed. Information about the success of the commands that were executed is written to anything.auto.log


Тут описан механизм.
Вряд ли у меня есть шансы.

Знаете, что меня смущает… Выглядит как крутая штука, когда реально нет никаких других возможностей настроить микротик, есть проблемы со стабильностью канала и пр. (я сам в первую очередь поклонник максимально надежных процессов), но вот интересно — если был обрыв связи по FTP, то может ли микротик случайно запустить половинчатый auto.rsc файл? А если их несколько качается в одном сеансе связи? Наверняка разработчики задумывались об этом (хотя не факт — ту же имплементацию OpenVPN over UDP их умоляли ГОДЫ реализовать, а совместимость IPIP-IpSec у микротика с другими корпорат.железками не на уровне 100%, тот же strongswan более надежен), но вот в доке ответа я при беглом просмотре не нашел.
Ну, и я не понимаю, чем хуже двухшаговый вариант (загрузка скрипта + /import) по сравнению с автостартом скрипта после загрузки.

Как по мне просто надо учитывать специфику. Если среда доверенная, например есть managment vlan или шифрованный туннель, то можно рассылать как угодно и даже через FTP. А если не доверенная, то там, естественно, нужно залить либо двумя шагами, сначала sftp/scp, а потом /import по ssh. Либо любым другим шифрованным механизмом.

Я никогда таким способом не пользовался, т.к. в dude есть намного более мощный и бесплатный механизм для работы с конфигурациями. Взять хотя бы очень интересную опцию как работу с оборудованием не доступным по l2/l3 от точки управления, но вполне доступным через цепочку mikrotik`ов и им мы через dude можем отправить команды или считывать телеметрию. Можно нечто подобное реализовать на ansible?
Тут не написано что автоматическое выполнение скрипта чем то отличается от /import something.rsc, за исключением записи статуса в лог. Где тут про откат конфигурации в случае ошибки в скрипте и тп?
Написал в поддержку. Посмотрим, что ответят.
1) Why auto import * .auto.rsc works just under FTP protocol and not work for sftp / scp.
2) Is there any plans for deploy sftp / scp auto import?
3) Is there some mechanism for handle upload errors like session disconnect and * .auto.rsc is not upload completely?
4) Is there some mechanism for error handling content of * .auto.rsc in case of some wrong syntacsis.

По факту несколько часов назад выкатили stable 6.46.1. Там есть пункт:
*) system — fixed "*.auto.rsc" file execution (introduced in v6.46);

Так вот я обновился, проверил, scp/sftp auto import все ещё не работают.
Выходит это не подкрепленные домыслы автора?
Плюс фишка auto.rsc. если конфиг который отправили с ошибкой, то весь скрипт откатиться и даст лог(не вкрячится в состоянии полтора). Там очень много тонкостей.


В первом же комментарии указали на то что, сейчас целесообразно сразу начинать использовать современные инструменты. Инфраструктура как код ( ansible + git) это действительно правильный, современный подход. А то что показал в статье автор, похвально, но я извиняюсь, так делали 15 — 20 лет назад, когда не было никаких инструментов автоматизации, и каждый админ, на своих коленках писал как мог. Сейчас на это нет смысла тратить время.
Автору — попробуйте все таки ansible, вам понравится.
SFTP was already working for a while but got broken in latest RouterOS versions. v6.47beta upcoming releases will contain a fix for the problem.

Best regards,
Mārtiņš S.

Скудненький ответ. Но хоть что-то. Будет значит нам sftp. Просто со временем.
Sign up to leave a comment.

Articles