Skurudo Blog(post)

Заметки и замечания, рассказы и пересказы.

Скрипт для обновления AddressList

Соорудил скрипт для обновления адрес листа или листов более или менее автоматически. Давно хотел завести что-то подобное для автоматизации.

Первоначальная задумка:

  • * у нас удаленно лежит адрес лист (где-то на веб сервере);
  • * мы по расписанию (это шедулер) забираем его к себе (это фетч);
  • * далее смотрим не нулевой ли размер, если нулевой — то выходим (пока не сделано, проверка идет по наличию файла);
  • * если все в порядке, то очищаем существующий адрес лист, импортируем новый и удаляем файл;

Из ограничений:

  • * пока не умеем работать с динамическими записями и очищать их;
  • * список адресов — это по сути rsc;
  • * список адресов там пока жестко задан адрес лист (непонятно получится ли это обратить в динамичный выбор);

Ссылка на сам скрипт:
https://github.com/skurudo/mikrotik-scripts/blob/master/ALAU/

BatMetal

Прекрасная подборка видео от ArhyBES на тему вселенной Batman’a и смежных ребят :)

* BatMetal (Dethklok — Face Fisted)

* BatMetal Return (Dethklok — Murmaider)

* BatMetal Forever (Brendon Small — My Name Is Murder, Powerglove — Batman, Dethklok — Awaken)

Mikrotik: Начало

С оборудованием Mikrotik меня познакомил где-то полтора года назад один хороший камрад. Мол, отличная штука, говорит — полезно в хозяйстве очень хорошо идёт. Сперва открещивался, пока не очень была понятна логика и идеология работы с устройствами. Потому как логика весьма инженерная, после домашних или начальных офисных маршрутизаторов сразу во всем разобраться было не так просто. Но после посещения МУМ, послушав доклады, пообщавшись с адептами, почитав интернет стало весьма интригующе.

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

Устройства исключительно радуют стабильностью работы. Из серии — настроил, поставил, забыл. А поскольку они работают на единой операционной системе RouterOS на всех устройствах мы видим единообразие в настройках и меню. Грубо говоря, мы можем делать что-то или проводить эксперименты на самом дешёвом железе за 15 баксов и потом сразу пересесть на нечто на два порядка дороже — элементы управления и логика работы никак не поменяется.

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

PS: Тогда же, чуть больше года назад я получил свой первый официальный сертификат :-)

Финальный список посещения фестиваля

В итоге фестивальный список срезался до трех картин. Так и хочется сказать — ну ничоси! :-)

  • Сегодня снова издевательский бэнто (Kyô mo iyagarase bentô)
  • Первая любовь (Hatsukoi)
  • Переезд по-самурайски (Hikkoshi daimyô!)

В списке могло бы быть еще пара картин, вроде «Фэйбл (Za Faburu)» и «12 ребят, которые хотят умереть (Jûni-nin no shinitai kodomo-tachi)», но в связи с ограниченным количеством билетом не срослось. Плюс не удается пойти в следующие выходные в связи неожиданной образовательной сессией.

Фестиваль японского кино в 2019 году

Как-то так получилось, что в связи со сменой работы, в прошлом году 52-ой фестиваль японского кино прошел мимо. Сил и желания сходить не было буквально никакого. Попробую наверстать в этом году, на 53 фестивале. Не смотря на то, что повторов кинолент не будет, идти на все не планирую. Предварительно заинтересовали следующие художественные фильмы:

  • * Судьба: История Камакуры
  • * Сегодня снова издевательский бэнто
  • * Первая любовь
  • * Фэйбл
  • * Отмывание квартир
  • * 12 ребят, которые хотят умереть
  • * Отель «Маскарад»
  • * Мы — маленькие зомби
  • * Мой папа — рестлер-злодей
  • * Переезд по-самурайски

Расписание:
19 ноября

  • Потанцуй со мной — КАРО 11 Октябрь  — CC-Info

20 ноября

  • Судьба: История Камакуры (2017) — КАРО 11 Октябрь — CC-Info

21 ноября

  • Сегодня снова издевательский бэнто (2019) — КАРО 11 Октябрь  — CC-Info

22 ноября

  • Первая любовь (2019) — КАРО 11 Октябрь  — CC-Info

23 ноября

  • Банан посреди ночи: правдивая история (2018) — КАРО 7 Атриум  — CC-Info
  • Фэйбл (2019) — КАРО 7 Атриум  — CC-Info

24 ноября

  • Маленькая песня о любви (2019) — КАРО 11 Октябрь  — CC-Info
  • Мы — маленькие зомби (2019)  — КАРО 11 Октябрь  — CC-Info

25 ноября

  • Отмывание квартир (2018) — КАРО 11 Октябрь  — CC-Info

27 ноября

  • Пришедший с моря (2018) — КАРО 11 Октябрь  — CC-Info

28 ноября

  • 12 ребят, которые хотят умереть (2019) — КАРО 11 Октябрь  — CC-Info

30 ноября

  • Фудзико: Пианистка тишины и одиночества (2018) — КАРО 11 Октябрь  — CC-Info

01 декабря

  • Отель «Маскарад» (2019) — КАРО 11 Октябрь  — CC-Info
  • Мой папа — рестлер-злодей (2018) — КАРО 11 Октябрь  — CC-Info

Не указана дата

  • Исповедь «неполноценного» человека: Осаму Дадзай и три женщины (2019) CC-Info
  • Переезд по-самурайски CC-Info

Кинотеатры:
КАРО 11 Октябрь

  • Москва, ул. Новый Арбат, д. 24.

КАРО 7 Атриум

  • Москва, ул. Земляной вал, 33 (ТРК «АТРИУМ»).

Каверзные вопросы микротоводам

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

Представьте себе, что случилось страшное — по какой-то неведомой причине у нас перестал открываться очень важный ресурс. Вот везде открывается, а из конкретного офиса — нет. Разбираться с провайдером и владельцем ресурса времени нет. Нужно срочно что-то придумать. Оперативно обеспечить доступ. Вот придумали по-быстрому использовать VPN. Выключенные маршруты — первый вариант, там работает не все — некоторые сервисы недоступны. Включенные маршруты из второго варианта, и теперь таки работает.

Если посмотреть на эту схему, то от нее пахнет легкими наркотиками. Настаиваю на том, что здесь можно назвать минимум две позиции, где есть существенный недочет. Можете попробовать испытать вопросы на коллегах :)

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

  1. Указан просто гигантский разбег по адресам, с таким успехом можно было бы зарядить весь трафик в тоннель. А это не всегда целесообразно и необходимо, не говоря уже про трафик и нагрузку. Отсюда может выйти подпунктом дополнение — поленились собрать IP-адреса сервиса и сделать маршруты по ним или же поленились использовать L7.
  1. Использование имени вместо адреса в шлюзе. Оно и так работает, конечно, но в этом место в случае реконнекта или изменений можно найти приключений, маршруты просто перестанут работать.
 Нет комментариев    175   2 мес   IP   Mikrotik   VPN

Группы пользователей в Mikrotik

С связи с расширением сети на даче появилась задача как-то группировать абонентов и что-то такое с ними вытворять — вводить ограничения и проводить мониторинг. Скорость и стабильность работы в связи со сменой оборудования и мобильного оператора возросла, но для спокойной жизни этого недостаточно. В задаче исходим из того, что у нас есть центральный маршрутизатор, в который сходятся несколько точек доступа. Сами точки доступа только передают подключение сразу в маршрутизатор без каких-либо затей. Если на Zyxel Keenetic функционал с двумя группами был из коробки в каком-то виде, то на Mikrotik нужно придумать что-то свое. Основная идея в том, что мы идентифицируем подключившегося по MAC-адресу и далее сопоставляем его с группой.

Сначала виделось два пути — делать дополнительные бриджи и раскидывать клиентов или делать vlan’ы. Делать бриджи только казалось хорошей идеей, на деле в них не было интерфейсов. Было создано несколько бриджей, с отдельными DHCP-серверами и в зависимости от MAC-адреса пользователю выдавался адрес из пула того или иного сервера. Пользователей так поделить удалось, но локальная и внешняя сеть в таком варианте не работает. Далее была идея использовать mac-based vlan. Но здесь мы сталкиваемся с тем, что не слишком удобно привязывать MAC-адрес и все равно нужно цепляться к интерфейсам. Других идей не было.

Находясь в сомнениях, я поделился своими мыслями с одним грамотным товарищем, и он натолкнул меня на другую идею, сказав — «зачем ты все пытаешься решить на L2, почему не хочешь делать управление разными сетями сразу?» Дальше товарищ отвлекся, а на меня в свою очередь снизошло озарение. Нет нужды городить огороды и развивать лопатостроение. Мух от котлет, то есть подключившихся пользователей, разделит как и в варианте с бриджами DHCP-сервер. Нам нужно задать несколько разных подсетей для разных групп пользователей. Пользователей поделит по MAC-адресу наш DHCP-сервер, добавляя в нужную группу — читай нужную подсеть. А дальнейшие манипуляции уже делать в Firewall / Queues. Осталось только реализовать схему и разбавить немного ручным трудом в виде работы с Leases.

Подготовка к внедрению, получаем аналоги групп:

Делаем немного QoS на Simple Queues:

И теперь в самое основное в Leases:

По результатам у нас пользователь попадает по умолчанию в Public сеть 192.168.1.0/24 с определенными условиями и ограничениями, оттуда вручную мы его можем перенести в другую «группу» или сеть с другими условиями, с более мягкими или жесткими ограничениями. Достаточно удобно, если не считать ручную работу.

 Нет комментариев    212   4 мес   DHCP   Keenetic   L2   L3   MAC   Mikrotik   OSI   RouterOS   Zyxel

Needless: лоли атакуют

Порой забавно встречать в сети коллажи, которые сам же и делал когда-то. Иногда даже с теми же самыми комментариями, которые были изначально.

В поисках хостинга DNS

В далеком 2011 году впервые озаботился вопросом выбора DNS хостинга, чтобы был понадежнее да поудобнее. С тех пор обращался к теме поиска несколько раз, но ничего идеального так и нет. Основная претензия к такого рода услугам — она либо дорогая, либо неудобная, либо все вместе. Складывается ощущение, что те, кто занимается разработкой или руководит внедрением, не имеют у себя с десяток доменов или в DNS им нужно поменять что-то такое специфическое один раз, к одному домену и происходит это раз в сто лет и можно немного потерпеть. Не скажу, что сам меняю что-то каждый день, но некоторая частота все-таки есть. Еще один случай из клинических — переезд. Сменить одну А-запись для одного домена не долго, а вот когда там еще TXT и для доменов 3-его и 4-ого уровня? Довольно продолжительно по времени получается.

Помнится, был сначала YPDNS, более всего близок по первоначальным требованиям, но просуществовал недолго и закрылся. Если не изменяет память, то у создателя не оставалось времени и мотивации на продолжение ведения этого дела. Пришлось по большей части смигрировать на PDD от Яндекс, однако после миграции всего в Connect я начинаю думать, что Яндекс тоже идет по какому-то своему пути и интересы у нас немного разные.

Чего бы сейчас хотелось от DNS хостинга:

  1. если сервис платный, то стоимость поддержки не должна быть астрономически высокой;
  2. серверы в нескольких гео-распределенных датацентрах поближе к магистральным каналам (на данный момент не самый критичный пункт, хотя несколько лет назад для меня это было важно — достаточно чтобы физически не в одном ДЦ);
  3. «быстрый» пинг (желательно до 10 мс, в идеале 1-5 мс);
  4. оперативная синхронизация между серверами;
  5. поддержка NS, A, AAAA, CNAME, MX, TXT, PTR и SRV;
  6. возможность изменения TTL по записям;
  7. возможность изменения SOA по домену;
  8. желательна поддержка DNSSEC;
  9. поддержка Round Robin желательна;
  10. возможность использования темплейтов (наличие инструмента или шаблона для создания — т. е. мы создаем шаблон с нужными записями и применяем его к домену);
  11. возможность массовой правки записей по домену (к примеру мы выделили несколько записей и хотим из удалить или мы выделили несколько записей одного типа — А-запись к примеру и хотим поменять там значение IP)
  12. возможность массовой правки записей по нескольким доменам (похоже для записи выше, здесь по большей части нас интересуют поля А-записей, TXT, SOA);
  13. и конечно стабильная работа, высокий аптайм как всегда.
 1 комментарий    72   8 мес   DNS   Яндекс
Ранее Ctrl + ↓