Skurudo Blog(post)

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

Настройка DoH в Mikrotik

Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

Теперь нужно провести небольшую артподготовку, а именно скачать и импортировать список корневых сертификатов. Делается это двумя командами:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare :)

Winbox, legacy mode

С выходом Winbox 3.22 появился в этой чудесной программе Legacy Mode, который позволяет, не смотря на усилия инженеров, подключаться менее защищенными методами к роутерам с RouterOS младше версии 6.43. Довольно полезная фишка для тех, кто не может или не хочет обновляться. Стоит заметить, что она выключена по умолчанию, включается впрочем просто:

Так что если вдруг видите ошибку — router does not support secure connection please enable legacy mode — знаете, что нужно включить.

Как я встретил ваш Brother

Задумались мы как-то взять какое-нибудь не сильно дорогое МФУ (чб, А4, печать, сканирование), чтоб запчасти и картриджи не дорогие да и функционал был поинтереснее и начали искать. В предложениях было много всего интересного, в том числе OKI и Xerox предлагали довольно четкие агрегаты, но вот ценовое предложение слегка расстраивало.

Начали присматриваться к Brother. Аппараты их низкого ценового сегмента по отзывам были вполне интересными и выносливыми, но вот о 5000 или 6000 серии отзывов было мало. Попробовал написать дилерам, которые продают сами аппараты, но никаких демо залов у них не было и живьем их не посмотреть. История так и закончилась бы ничем, если бы не написал в российское представительство.

Подозреваю, что напрямую им пишут не так часто. Не сразу, но на письмо мне ответили. Как водится поблагодарили за интерес и мы обменялись контактами. А что после того, как мы созвонились и осознали, что хотели бы пообщаться и посмотреть аппараты живьем, плюс потыкать в меню некоторых из них, ничего не оставалось, кроме как встретиться лично. Со стороны Brother получил приглашение и посетил их офис недалеко от станции метро Белорусская, что на улице 1-я Тверская-Ямская. Там мне довольно быстро смогли показать интересующие меня модели. Поскольку они были последними и довольно новыми, они у них были прямо в офисе. Их можно было открыть, посмотреть устройство и задать вопросы. Ко всему прочему удалось пообщаться с их техническим специалистом на предмет меню и особенностей работы аппаратов, оценить функционал. Попутно и удалось для себя решить, что 5750 и 6800 — весьма интересные по стоимости и возможностям аппараты

Искренне рад, что представительство открыто к встречам с людьми практически «с улицы» (достаточно было пояснить задачу и договориться о встрече.) Хотя по сути они проводят прямых продаж — ведь по сути закупки шли через дилеров, таким образом раскрывают свой бренд больше косвенно. От себя хотел бы поблагодарить Ольгу Степанову и Алексея Попкова, очень уж мы плодотворно пообщались.

Onlime IPTV + Mikrotik

Про связку Mikrotik с разными IPTV провайдеров можно прочитать в этих самых интернетах, но суть обычно сводится к тому, что у нас какая-то несложная схема с дополнительным кабелем к приставке и в роутер, а там уже как-то разбираемся. Дополнительный кабель мне тянуть не очень хотелось, включить приставку было интересно, не трогая существующую схему подключения.

Визуально настройки выглядят как на картинке ниже:

  1. Первым делом ставим пакет multicast, без него можно не продолжать — ставим традиционным способом: скачиваем дополнительные пакеты, закидываем в роутер и перезагружаемся;
  2. В пункте Routing появится IGMP Proxy — нам туда;
  3. Нам нужно создать логику для нашей IGMP Proxy — кто апстрим и кто слушатель. Создается аналогично правилам;
  4. Настройки для апстрима — откуда приходить наш поток, у нас это ether1 — порт провайдера или WAN;
  5. Настройки для слушателя — в зависимости от вашей сети, но чаще все остальные порты в бридже, потому логичнее отдавать на него. У вас могут быть и более сложные варианты, соответственно, можно выбрать и другое;
  6. Опциональный пункт, который зависит от ваших firewall filter rules — если все наглухо заблокировано, то нужно будет открыть UDP в цепочке forward. В ограничителях можно ничего не выставлять, но безопаснее будет сократить диапазон разрешенных адресов до сети провайдера или сервера вещания (нужно учитывать, что он может меняться).

Можно праздновать победу и отключать приставку от телевизора, особенно если вы его не особо смотрите :)

.master тянет за собой все(х)

Многие пользователи интернета почти наверняка слышали о ситуацию с .masterhost. Искренне жаль, что такая судьба постигла в прошлом родную, в прошлом мощную компанию. Еще больше жаль тех, кого настигла такая неприятная ситуация. Но сейчас я хотел бы поволноваться о другом. Дело в том, что в группе компаний .masterhost есть аккредитованный регистратор доменных имен — .mastername. Отсюда у владельцев доменов, к которым и я себя отношу, может возникнуть несколько вполне не иллюзорных сложностей.

Сложность первая — NS-серверы, у некоторых из пользователей они были и есть, т. е. те самые люди, которые пользовались DNS-регистратора. Работу вроде как восстановили и плача по этому поводу слышно меньше, но изменить ничего нельзя: ни ns-серверы, ни dns-записи. Биллинг лежит.

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

Сложность третья — убежать все также нет возможности. Может быть по причине того, что домен не продлен, или отсутствует техническая возможность у регистратора. Биллинг лежит и auth code не приходит.

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

На первый же взгляд среди них следующие нарушения:

2.3. Регистратор обязан бесплатно и круглосуточно предоставлять пользователю (администратору) необходимую и достоверную информацию, указанную в разделе 3 настоящих Требований.
2.4. Регистратор обязан иметь службу поддержки пользователей (администраторов).
2.5. Регистратор обязан бесплатно и круглосуточно принимать от пользователей (администраторов) информацию о технических неисправностях, препятствующих пользованию услугами регистрации доменных имен; устранять в сроки, установленные самим Регистратором и опубликованные на его сайте, неисправности, препятствующие пользованию услугами, связанными с регистрацией доменных имен.
2.8. Регистратор обязан поддерживать систему учета услуг, учитывающую особенности оказания услуг регистрации доменных имен.
3.4. Сайт регистратора и личный кабинет пользователя (администратора) должны быть доступны для предоставления сведений и информации 24 часа в сутки 7 дней в неделю. Регистратор обязан уведомлять пользователей (администраторов) о времени и продолжительности возможных перерывов в работе сайта и/или личного кабинета, связанных с обслуживанием технических средств, путем опубликования информации на сайте регистратора в срок не позднее чем за 48 (сорок восемь) часов до момента наступления перерывов. При этом общая продолжительность возможных перерывов не может превышать 72 (семьдесят два) часа за 12 месяцев.
8.1. обеспечить возможность администратору доменного имени направить запрос/обращение регистратору по вопросам регистрации и/или продления регистрации доменного имени посредством, как минимум, следующих каналов связи: по телефону, электронным способом;
11.4.Регистратор обязан предоставить пользователю (администратору) личный кабинет для взаимодействия с информационной системой Регистратора. Функции информационной системы Регистратора, перечисленные в подпунктах 11.3.1 и 11.3.3.-11.3.8. настоящих Требований, должны быть доступны пользователям (администраторам) через личный кабинет.
11.7.Регистратор обязан располагать средствами защиты от действий третьих лиц, направленных на получение несанкционированного доступа к информационной системе Регистратора и/или программно-аппаратному комплексу Регистратора, или на нарушение их нормального функционирования.

На данный момент конца конфликта не видно. Новости на сайте регистратора не обновляются... Будем конечно посмотреть за этой печальной историей. И даже, если вдруг, что-то наладится, то требования были нарушены и доверие потеряно.

Куда пойти учиться... Mikrotik

...регулярно вижу вопросы из серии: «Где бы мне научиться работать с оборудованием Mikrotik, а то что-то ничего непонятно». Более или менее закрою вопрос этим опусом.

Есть буквально несколько способов изучить предмет:

  1. Самостоятельно изучение — внимательно читаете эти самые интернеты, изучаете официальную документацию, форумы, аккуратно применяете статьи в блогах (так как информации много устаревшей и не всегда рабочей). Из плюсов — условно бесплатно. Минусы — сравнительно не быстро, большой поток информации, которую нужно фильтровать.
  1. Обучение заочное — можно пройти онлайн курс Дмитрия Скоромнова, экзамен сдавать или не сдавать — дело ваше. Курс довольно подробный. По нему я готовился сдавать MTCNA и довольно таки он мне сильно помог. Плюсы — самостоятельно изучение в свободном ритме, можно проконсультироваться по электропочте, полный и добротный курс. Минусы — не будет официального сертификата, нужно немного заплатить.
  1. Обучение очное лайт-версия — у Романа Козлова есть курс молодого бойца. Проходит раз в 2-3 месяца и там можно узнать основное по работе с оборудованием. Плюсы — хорошее начало, символическая плата, приятная атмосфера. Минусы — обычно в будний день и нужно ехать ножками в Москву.
  1. Обучение реальное и живое — речь о начальном курсе MTCNA, это полноценное обучение с экзаменом и сертификатами. Здесь у вас довольно широкий выбор как места, так и тренеров. Обычно говорят, что первый курс можно слушать практически у всех. Кого-то определенного рекомендовать не буду — здесь на ваш выбор. Сильные и слабые стороны есть у всех тренеров. Плюсы — полноценное обучение, сертификат (если сдадите экзамен). Минусы — затраты по деньгами и времени (3-4 дня курс).

Ошибки lastmod в sitemap

В Эгея версии 2.8 появился свой sitemap и вроде как стало не нужно использовать костыли для его генерации, но в нем был недостаток, а именно формат даты в lastmod. На него ругался в частности валидатор от Яндекса, что довольно сильно расстраивало.

Исправить поведение довольно не сложно — было сделано на версии 3387 (e2_distr_v3387). Нужно слегка отредактировать system/core.php и искать такую конструкцию (она встречается дважды):

echo '<lastmod>';'

Конструкцию со временем менять на вот такую:

('Y-m-d\TH:i:s+03:00'

При этом не забываем обнулить user/caches.

Обратите внимание на то, что у нас появился разделитель «Т» — в коде соответcвенно «\Т», а также смещение времени по UTC — для Москвы это +03:00. Делается это в соответствии с W3C Datetime (Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)).

Обратите внимание на выделенные части:

Результат:

PS: Проблема была как минимум до альфы-беты 2.9, в ней дату упростили, оставив по стандарту только дату без учета времени, т. е. в таком виде 2020-02-07). Проверялось на версии v3543.

Gooooogle Girl

Gooooogle Girl — милый такой клип от MAD SHOW BOYS, не настолько токсичный как Google that shit! от Тарин Саутерн .

Сетевые технологии по версии «за щекой»

Доходчиво и понятно, какая из технологий как работает:

UDP: Кинул тебе за щеку
ТСР: Кинул тебе за щеку, проверяй
SNMP: Щас посмотрим, кто тебе за щеку пихал.
POP3: Вам письмо за щеку
IEEE 802.11: Радио «За щеку FM»
P2P: Давай сейчас я кину тебе за щеку, а потом ты мне
SIP: Давай послушаем, как тебе за щеку кинут
IPv6: Сейчас тебе за щеку прилетит, только будет длиннее обычного, приготовься
IRC: Давай дед тебе за щеку кинет
Ethernet: И еще 15 способов кинуть тебе за щеку
ARP: Кто знает этого, которому можно кинуть за щеку?
ICMP: Кинул тебе за щеку, ДОШЛО?
IGMP JOIN: Будьте добры, киньте мне тоже за щеку
NTP: Кажется, пришло время принять за щеку
SSH: Дам тебе за щеку, только никому не говори
MTU/MRU: Кинул тебе за ще
RIP: За щеку могут дать вот там, но их надо ещё попросить, они большие шишки
OSPF: За щеку дают там
BGP: Передайте за щеку всей маршрутке!
STP: Здесь только я могу тебе за щеку напихать
LACP: Ща кинем хэш-функцию, она укажет того, кто тебе напихает за щеку.
LLDP: За щеку тебе может напихать этот, вот тот и тот. Два из них твои соседи.
PBR: Это Олег, он из другого города, но он напихает тебе за щеку
QoS: Я напихаю тебе за щеку, но сначала мы подождем моего друга
DHCP: Что? Хочешь, чтобы я тебе за щеку напихал?
802.3ad: Кинул тебе за обе щеки
802.5: Кинул тебе за щёку, передай дальше
VRRP: Ты никогда не узнаешь кому из близняшек ты кинул за щеку
BFD: Кинул за щеку и тебе откусили
ACL: Кину за щеку после свадьбы
DNS: Спроси у меня, как зовут того, кто кинул тебе за щеку
WebSocket: Лови за щеку, лови за щеку, лови за щеку
amqp: Встаньте в очередь для получения за щеку
Graphana: Здесь ты можешь посмотреть как, кто, с какой скоростью и длиной давал тебе за щеку
Proxy: Надену карнавальный костюм и кину за щеку
VPN: Дам за щеку, но только у тебя дома
MQTT: Здрасьте, кто тут на за щеку подписывался? Принимай!
TOKEN RING: Чья сейчас очередь принимать за щеку?

Оригинал, насколько я смог установить — i_am_romochka

Сравнение значений в скриптах

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

Не правильно
$Installed < $Latest

Правильно
$Installed != $Latest

Например мы сравниванием версии 6.45.6 (Installed) и 6.46 (Latest). Получается, что Mikrotik берет значение как число и выходит, что 646 (Latest) никак не может быть больше 6.45.6 (Installed) . В итоге неправильное сравнение больше-меньше конечно будет работать, но не во всех случаях. Для обеспечения универсальности лучше использовать сравнение. Иными словами, если у нас есть различия в версии, то явно нужно обновляться.

Ранее Ctrl + ↓