Достаточно давно появилось желание завести свой сервер одноразовых паролей. Искал, не особо торопливо, как обычно. Отчасти потому, что еще немногие серверы поддерживали такой механизм аутентификации. Да и данных, которые нужно защищать было немного. Позже появились сервисы типа госуслуг, в почте стало храниться больше «чувствительных» данных, стало необходимо ограничить доступ к некоторым функциям своего сервера... В общем, причин накопилось достаточно. Про сервер OTP (One Time Password) стал вспоминать всё чаще и вот на днях мне попалась один простой, но в тоже время достаточно функциональный сервер 2FAuth.
Как пишет автор, он создал его потому, что:

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

Какие есть «плюсы» данного решения:

• возможность регистрации новых пользователей. Кто-то отнесет ее к «минусам», я не вижу ничего плохого. Можно отключить в настройках.
• Восстановление пароля от своей учетной записи, используемой для входа. Не проверял.
• Возможность импорта и экспорта данных.
• Возможность загрузки QR-кода из файла.
• Возможность ручного ввода данных (сервис, учетная запись, секретный шифр).
• Поддержка TOTP, HOTP, Steam, WebAuthn.
• Загрузка логотипов. Мелочь, а приятно.
• Поддержка SQLite, MariaDB, MySQL, PostgreSQL и SQL Server (внезапно).
• Присутствует REST API (снова сюрприз).
• Есть темная тема.

Пройдемся по «минусам»:

• Отсутствует приложение для мобильных телефонов, только веб-страница.
• Нет поддержки кодов, генерируемых Яндексом. То есть у вас не получится запихать в сервис OTP от Яндекса. Ну тут «на любителя».
• На мой непрофессиональный взгляд слишком много файлов находится в папке.

Теперь немного скриншотов:

Добавление движения общественного транспорта в Home Assistant

Наконец-то у меня получилось. Как обычно, делал всё сильно неспешно при наличии свободного времени и желания. «Воды» не будет, поэтому поехали.
Сейчас не вспомню как, но как-то я вышел на адрес сайта, который отдает данные в формате JSON. Так как меня интересовал в первую очередь конкретный маршрут трамвая, то я получил вот такой вот адрес:

https://mu-kgt.ru/informing/wap/marsh/?m=6%F2%F0&action=getMarshData

Что здесь интересного?

• m=6%F2%F0 — номер маршрута и обозначение типа транспорта. В данном случае часть «%F2%F0» — это всего лишь русские буквы «тр», то есть трамвай. Для троллейбуса это будет просто «т» или «%F2», для автобуса это либо «а», либо вообще без буквы — если честно, не пробовал, да и лень было.
• action=getMarshData — вызывает одноименную функцию в скрипте.
  Переходим в Home Assistant. Здесь я создал новый сенсор в configuration.yaml такого вида:

sensor:
  - platform: rest
    resource: https://mu-kgt.ru/informing/wap/marsh/?m=6%F2%F0&action=getMarshData
    name: Трамвай 6 прибытие
    unique_id: tram6_arrival
    value_template: "{{ value_json.ts_line.A[-1].st_arrive }}"
    scan_interval: 120

Самое важное здесь — value_template, в котором содержится путь до нужной остановки, по которой получаем информацию о времени прибытия. Буквой «А» закодировано направление движения транспорта, которое вы видите в левой части экрана, а буквой «В» — в правой части экрана.

Такие же буквы присутствуют на самом сайте и в приложении.

Я сделал два сенсора: прибытие и убытие, чтобы ориентироваться когда придет следующий трамвай на конечную остановку. Можно оформить и получше, но это — не главное.

Вид сенсоров в Home Assistant

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

Остановка: Детский кинотеатр «Мечта» (код 336)

В скобках мы и увидим код остановки. В данных, которые нам отдает скрипт по запросу, это код содержится в поле st_regnum.

И еще небольшое дополнение. Значения «0» и «-1», конечно, хороши для выбора конечных остановок при условии, что мы не знаем количество остановок на маршруте, который может измениться, например, из-за ремонта дороги или аварии. Следующий шаблон выбирает остановку с заданным кодом:

value_template: >-
  {% set stops = value_json.ts_line.A %}
  {% for stop in stops %}
    {% if stop.st_regnum == 1989 %} {{ stop.st_arrive }} {% endif %}
  {% endfor %}

Обновлено. Автобусы маркируются без буквы в URL, только номер маршрута.

Попробую сравнить эти две системы «умного дома».
На Domoticz я «просидел» несколько лет. Эта система была хороша тем, что имела низкий порог вхождения, не требовала особых ресурсов и имела достаточно много возможностей. Что я понял спустя некоторое время:

1. Интерфейс достаточно жестко закреплен. Вы не можете создавать свои вкладки (разделы), только заданные разработчиками.
2. Нельзя сгруппировать датчики одного устройства в группу. Один датчик — одна карточка. Которые могут быть разнесены по разным разделам. Например, данные из домашней метеостанции будут присутствовать в трех разделах, между которыми нужно переключаться, чтобы получить всю информацию от нее.
3. Есть темы оформления, но их мало и не все работают корректно. Некоторые предъявляют требования к именам устройств, чтобы была возможность объединить их в одну карточку.
4. Чтобы получить данные с сайта, из операционной системы или что-то еще, выходящее за рамки протокола MQTT — придется использовать python или lua. Тут, кстати, небольшой «плюс» — скрипты хранятся в базе данных. После запуска Domoticz они выгружаются во внешние файлы. Зачем? Ладно, пусть.
5. База данных имеет формат SQLite. Тут свои «плюсы» и «минусы».
6. Группа Domoticz в Telegram, в которой я состоял, «топит» за использование «домика» в связке c Node-Red. Я не любитель установки множества программ на сервер, поэтому от последнего отказался. Что, с одной стороны, сильно меня ограничило в изменении интерфейса системы, с другой... Да ну его нафиг! Там свои ограничения.
7. Несмотря за заявленную несколько лет назад возможность синхронизации данных между несколькими серверами Domoticz, она так и не была реализована. Судя по некоторым данным, разработчики просто «забили» на неё.
8. Мне так и не удалось подключить часть устройств, типа пылесоса Xiaomi, телевизора Samsung, чайника Redmond. И, уверен, в ближайшее время, этого не будет в «домике».
9. Система может просто не запуститься после обновления ОС или если вы допустили ошибку с своем скрипте. Может не понравиться версия glibc, python или его библиотеки. Проверка целостности отсутствует напрочь.
10. «Умные» колонки вы не подключите.

Скорее всего, было что-то еще, что меня не устраивало в этой системе, но я перечислил основное. К тому же на меня порой «находит» и я начинаю экспериментировать. Поэтому качаем образ Home Assistant для KVM и начинаем пробовать что он может.

1. У меня много «простых» устройств, работающих по протоколу MQTT. Их пришлось прописать ручками. Копипаста с небольшими правками сильно помогла. Это был начальный этап, я еще ничего не знал. НА может обнаруживать такие устройства сама.
2. Пылесос, телевизор, чайник «влетели» как родные, после установки нужных дополнений.
3. Базу данных в формате MySQL пришлось подключать ручками. Основной формат опять же был SQLite, но для большой истории показаний он не годится. Перенес данные из Domoticz в Home Assistant (есть скрипт в интернете).
4. Сделал нужные мне разделы (вкладки) в интерфейсе, занес в них нужные устройства с нужными параметрами. Разница с Domoticz просто огромная.
5. Оповещения в Jabber, Telegram, на почту подключаются достаточно просто.
6. Нашел несколько групп в Telegram по этой системе. Общение между участниками идет постоянно, поэтому пришлось отключить уведомления.
7. Парсинг данных с сайтов вообще порадовал — достаточно указать URL, с которого будешь забирать данные и тэг, который нужно искать. Ну и номер тэга иногда.
8. Есть проверка ошибок конфигурации перед перезапуском. Если найдет — выдаст предупреждение. Это вообще кайф :-)
9. По ресурсам, конечно, более требовательна, но оно того стоит.
10. Хотите подключить колонку яндекса или марусю — не вопрос!

Наверное, на этом закончу. Продолжу тему в другой заметке — там уже много чего описать.

Случай, когда ваш домен располагается на reg.ru

Можно, конечно, воспользоваться сторонними библиотеками, но я не любитель ставить что-то стороннее, если можно обойтись своими силами. Поэтому пришлось потратить время на написание и тестирование bash-скрипта с именем authenticator.sh:

#!/bin/bash

#Основные параметры
domain="kini24.ru"
username="graywolf"
password="********"
# Этот параметр менять не нужно
subdomain=""

# Корректно задаем судбдомен
# Если обрабатывается основной домен, то субдомен будет _acme-challenge
# Если обрабатывается субдомен, то строка будет вида _acme-challenge.subdomain
if [[ $CERTBOT_DOMAIN = $domain ]]
then
  subdomain="_acme-challenge"
else
  subdomain="_acme-challenge.${CERTBOT_DOMAIN%.$domain}"
fi

# Чисто для информации
/usr/bin/echo "Requesting $CERTBOT_DOMAIN"

# Запрос на удаления текущих записей
txt_delete="input_format=json&input_data={\"username\":\"$username\",\"password\":\"$password\",\"domains\":[{\"dname\":\"$domain\"}],\"subdomain\":\"$subdomain\",\"record_type\":\"TXT\",\"output_content_type\":\"plain\"}"

# Запрос на добавления записи
txt_add="input_format=json&input_data={\"username\":\"$username\",\"password\":\"$password\",\"domains\":[{\"dname\":\"$domain\"}],\"subdomain\":\"$subdomain\",\"text\":\"$CERTBOT_VALIDATION\",\"output_content_type\":\"plain\"}"

#Можно проверить при желении
#/usr/bin/echo "Certbot parameters:"
#/usr/bin/echo "Current domain: $CERTBOT_DOMAIN"
/usr/bin/echo "Validation string: $CERTBOT_VALIDATION"
#/usr/bin/echo "Delete request: $txt_delete"
#/usr/bin/echo "Add request: $txt_add"

# Запрос на удаление ВСЕХ TXT записей
if [[ $CERTBOT_DOMAIN != $domain ]]
then
 #/usr/bin/echo "Remove all TXT records"
  /usr/bin/curl --silent --data "$txt_delete" "https://api.reg.ru/api/regru2/zone/remove_record"
fi

# Запрос на создание TXT записи
#/usr/bin/echo "Add new TXT record"
/usr/bin/curl --silent --data "$txt_add" "https://api.reg.ru/api/regru2/zone/add_txt"

# Проверяем что нужная TXT запись появилась. Иначе ждем пока данные обновятся
#answer=""
#while [[ $answer != $CERTBOT_VALIDATION ]]
#do
#  /usr/bin/echo "Requesting DNS record"
#  answer=$(/usr/bin/dig @77.88.8.8 $CERTBOT_DOMAIN txt +short | /usr/bin/tr -d \" | /usr/bin/egrep $CERTBOT_VALIDATION)
#  /usr/bin/sleep 60
#done

if [[ $CERTBOT_REMAINING_CHALLENGES -eq 0 ]]
then
  sleep 15m
fi

# Выводим количество доменов, которые осталось обработать
/usr/bin/echo "Remaining challenges: $CERTBOT_REMAINING_CHALLENGES"

Логика скрипта следующая. В начале задаются основной домен, имя пользователя и пароль от личного кабинета reg.ru. Параметр subdomain менять не нужно, он «вычисляется» по ходу выполнения скрипта. Далее если обрабатывается основной домен, то поддомен становится равным _acme-challenge, иначе в конец еще добавляется поддомен. Формируется строка для удаления всех (!) текущих записей типа TXT, если обрабатыается поддомен. Записи для основного домена просто добавляются (тут да, небольшой косяк, нужно немного дописать скрипт).
Затем, после добавления DNS-записи скрипт должен был запрашивать все записи TXT и, после появлении нужной, продолжать выполнение, но тут скрипт уходил в бесконечный цикл, поэтому я его закомментировал полностью. Сможете исправить — буду благодарен.
На последнем шаге скрипт, если доменов для регистрации не осталось, ждет 15 минут (время обновления записей у reg.ru от 15 минут до 1 часа) и возвращает управление команде certbot.

Вызывается скрипт примерной такой командой:

certbot certonly --manual --agree-tos --manual-public-ip-logging-ok --email admin@kini24.ru --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --domain *.jabber.kini24.ru --domain *.meet.kini24.ru --domain *.kini24.ru --domain kini24.ru --rsa-key-size 2048 --key-type ecdsa --elliptic-curve secp256r1 --redirect --uir --staple-ocsp --must-staple --hsts --manual-auth-hook /root/authenticator.sh

В этой команде следующие параметры:
certonly — только получение сертификата;
agree-tos — принимаем пользовательское соглашение;
manual-public-ip-logging-ok — соглашаемся на публикацию нашего IP-адреса;
email — указываем свою электронную почту для уведомлений;
preferred-challenges — выбираем тип проверки. Для wildcard-сертификатов это только DNS;
server — указываем сервер сертификации;
domain — перечисляем свои (суб-)домены;
rsa-key-size — указываем «размер» ключа. Значение 2048 по умолчанию, оставил на всякий случай;
key-type — тип ключа. Снова указано значение по умолчанию;
elliptic-curve — «кривые». Тут тоже значение по умолчанию;
redirect — перенаправлять с http на https$
uir — добавляет в ответ заголовок Content-Security-Policy со значением upgrade-insecure-requests;
staple-ocsp — «сшивание» сертификатов;
must-staple — обязательное «сшивание»;
hsts — принудительная активация защищенного режима, т. е. https;
manual-auth-hook — запуск своего скрипта.

Побывало у меня 2 «умных» чайника: Redmond RK-G211S и Fiesta DK-1G. Первый отработал около 3 лет, вторым пользуюсь и сейчас. И, внезапно, захотелось их сравнить, выделить «плюсы» и «минусы». Поехали.

Redmond RK-G211S
Вот наш первый герой (здесь и далее фото взяты из интернета):

Начну с «плюсов».

1. Мощный. Быстро кипятит воду.
2. Тихий. У меня маленький ребенок,поэтому любой шум будет излишним.
3. Удобное управление кнопками на ручке чайника и через приложение.
4. Поддержание заданной температуры.
5. Возможность задать время суток, когда чайник должен подогреть или вскипятить воду.
6. Можно использовать в качестве ночника в темное время суток.
7. Градуировка нанесена на внешнюю часть и хорошо видна.
8. Можно посмотреть общее потребление электроэнергии чайником.
9. Температура воды подсвечивается соответствующим цветом: красный, желтый, зеленый, синий.

К сожалению, «минусы» тоже присутствуют и для меня они оказались существенными.

1. Форма носика. За всё время использования я так и не привык тонкой струйкой наливать воды из него. Ну действительно, дизайнеры, поменяйте форму на более привычную. И данная просьба относится не только к этой модели. Очень раздражал этот момент.
2. Удаленное управление через bluetooth. Через две стены смартфон до чайника не «достает». Если хотите нормально управлять чайником — купите специальный шлюз по такой же цене (или уже дороже?), либо используйте смартфон (планшет) с установленным приложением-шлюзом. Сама компания-производитель говорит, что выбор в пользу bluetooth сделан для увеличения безопасности пользователя. В связи с нежеланием покупать что-то еще для управления чайником не получилось ввести его в систему «умного» дома.
3. Датчик температуры воды. Видели торчащую «пипку» из дна чайника? Это датчик температуры. Опять же, какой разум сделал его стеклянным и придумал так его расположить. К чему это ведет? Иногда нужно два-три раза подряд вскипятить воду. Иными словами, вскипятил один раз, слил воду, налил новую и еще раз включил чайник. Если вы нальете холодную воду сразу после кипячения, то велика вероятность того, что стеклянная крышка, закрывающая датчик, просто лопнет от перепада температур. Слышали когда-нибудь как трескается стекло при перепаде? Я слышал. Хорошо, что на работе это не сказалось. По крайней мере, я не заметил.
4. «Забывчивость». Как только вы снимете чайник с подставки он сразу забудет всё, чему вы его «учили». Придется выставлять все параметры заново. Для этого нужно, как минимум, чтобы смартфон с управляющим приложением были в зоне досягаемости чайника.
   В интернете можно найти способ добавления аккумулятора в чайник для предотвращения таких ситуаций, но... Мой опыт показал несостоятельность такого метода. Аккумулятора хватило примерно на полгода, после чего он просто вышел из строя.
5. Кнопки на ручке закрыты тонкой пленкой, которая быстро достаточно быстро стирается до дыр. Без комментариев.
6. Пластиковый корпус, можно обжечь руки.

Через 3 года использования чайник сломался — сгорел ТЭН. На замену ему пришел новый.

Fiesta DK-1G
Второй наш герой обзора:

«Плюсы»:

1. Удаленное управление через WiFi. Более удобно, быстро и, как мне кажется, надежно. В пределах дома нет ограничений на расстояние между смартфоном и чайником. Да и вообще нет ограничений, можно управлять из любой точки мира, где есть интернет.
2. В отличие от своего «соперника» этот чайник ничего не «забывает» после снятия с подставки. Или сразу подгружает данные из интернета — пока не уверен. В любом случае занимает это пару-тройку секунд, не больше — ровно столько длится подключение к домашней сети WiFi.
3. Корпус с двойными стенками. Сразу после кипячения корпус снаружи едва теплый.
4. Поддержание заданной температуры.
5. Возможность задать время суток, когда чайник должен подогреть или вскипятить воду.
6. Носик стандартной формы. Кружку можно налить за несколько секунд против примерно 30 секунд у Редмонда.

«Минусы»:

1. Градуировка нанесена на внутреннюю часть да еще и со стороны ручки. Наливать воду и одновременно контролировать ее уровень у вас не получится. Почти. Нижнее отверстие в корпусе перед носиком почти соответствует максимальному уровню воды, так что можно ориентироваться на него.
2. Более шумный, чем Редмонд. Хотя, казалось бы, должно быть наоборот.
3. Через некоторое время (не засекал, но навскидку примерно через час-полтора) гаснет экран, отображающий состояние чайника и температуру воды. Приходится снимать с подставки и возвращать его обратно.
4. При установке на подставку издает короткий писк. Зачем? Также при включении кипячения пищит два раза: первый — включение, второй раз — начало кипячения. Тоже не понимаю этот момент, ну да ладно.
5. Чтобы ввести его в систему «умного» дома пришлось проделать множество нестандартных действий. И речь сейчас не об Алисе от яндекса, а о таких системах как Home Assistant или Domoticz. С Алисой проблем вообще не возникло, подключил за пару минут.

И пара «спорных» для меня моментов.

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

В общем и целом, Fiesta DK-1G мне пока нравится больше, чем изделие от Редмонда. Я, наверное, даже рад, что моим первым опытом с такой техникой стал именно RK-G211S — он позволил мне точно определить чего я жду от «умного» чайника и с чем я точно не хочу сталкиваться каждый день.

Я несколько лет бился с запуском этой программы под разными версиями линукса: Alt Linux, Ubuntu, другие. И всё время натыкался на одну и ту же ошибку: «На найдена точка входа UserLogonExA в библиотеке ADVAPI32.DLL». Перепробовал множество способов, описанных в интернете. Ничего не помогало. Сравнительно недавно наткнулся на один, но из-за текущих дел опробовать не успел. А тут случилось неудачное обновление, база некорректно обновилась, пришлось откатываться и заодно решил попробовать — чем черт не шутит. Итак, алгоритм такой (предполагается, что wine уже установлен):

1. Монтируем сетевую папку на свой компьютер. Например, в /mnt/cons.
2. Запускаем winecfg, добавляем новый диск (пусть D:) и указываем смонтированную папку /mnt/cons.
3. Из консоли запустить файл cons.exe с параметрами пока не получилось, поэтому запускаем winefile и уже из него cons.exe.
4. При запуске соглашаемся с путями, которые нам предложила система (или изменяем на свои).
5. На рабочем столе появляется ярлык на cons.exe, но запустить система его не дает — выдает ошибку «Разрешите запуск». Галочка «Запускать как программу» установлена, но этого мало. Идем дальше.
6. Устанавливаем еще один пакет:

sudo apt install dbus-x11

7. Запускаем:

dbus-launch gio set '/home/kopytov/Рабочий стол/ConsultantPlus.desktop' "metadata::trusted" true

8. Обновляем рабочий стол и спокойно работаем с Консультантом.

Если нужен запуск системы с ключами, то добавляем их в desktop-файл.

«Генератор идей» в голове порой не дает нормально поспать. Вот зачем мне в голову уже за полночь пришла мысль попробовать подключить все устройства, которые есть в доме, к Алисе? Хорошо, что процесс не занял много времени и я успел более-менее нормально выспаться.
Первой «жертвой» стал телевизор Samsung. Первая попытка подключения была неуспешной — телевизор не был зарегистрирован в личном кабинете производителя. Пришлось установить программу SmartThings на телефон, войти в личный кабинет, добавить туда телевизор и уже после этого можно было добавить его в Алису. Немного побаловался голосовым управлением и пошел спать.
Утром сделал еще несколько попыток голосового управления и понял, что есть вещи, с которыми нужно будет разобраться:

1. Нельзя включить ТВ через Алису. Скорее всего, и не получится. В принципе, пока не критично. Но мысли как это обойти уже есть.
2. Нельзя переключать каналы, сказав, например: «Включи канал СТС на телевизоре». Но можно переключить канал, сказав его номер. Кто помнит какой телеканал под каким номером сохранен в вашем телевизоре? Вот и я не помню.
3. Нельзя переключить источник сигнала с HDMI на антенну, сказав пресловутую фразу «Включи канал СТС на телевизоре».
4. Запускать Алису на телефоне, чтобы управлять телевизором голосом — долго. Быстрее использовать кнопки в SmartThings или другом стороннем приложении.

Вторым устройством стал чайник Redmond. Им более-менее удобно было управлять с телефона через фирменное приложение. Из «минусов», которые меня раздражали, основным неудобством было то, что чайник подключался через bluetooth. Попробовал было подключить его через донгл к домашнему серверу, но «что-то пошло не так» и я забил.
Подключить чайник пока что не получилось. Возможно, сказалось то, что он был вне зоны действия bluetooth моего телефона. Возможно, для полноценного управления чайником нужен шлюз. Пока что непонятно, поэтому... Будем устанавливать android в виртуальную машину и пытаться настраивать его в качестве этого самого шлюза. Это пока что в процессе.
Следующим шагом стало подключение робота-пылесоса Xiaomi. Схема была такой же, как и с предыдущими двумя устройствами: авторизуемся в личном кабинете производителя, проверяем, что устройство там есть, заходим в приложение «Умный дом» от Яндекса и добавляем в него пылесос. Тут возник нюанс: пылесосов у меня добавлено два — один в моем доме, второй — у мамы. И приложение, ничуть не сомневаясь в своей правоте, успешно добавило оба в мой дом. Пришлось создавать второй дом и переносить туда мамин пылесос, чтобы случайно не запустить его убираться.

Увидел, что стали появляться наклейки с QR-кодами в транспорте для оплаты проезда. Видимо, приложение вышло из стадии тестирования и вошло в стадию эксплуатации. Что ж, посмотрим, что там наваяли... Никаких особых ожиданий от приложения не было. Несколько напрягало то, что сменился разработчик — это обычно влечет за собой полную переработку программы. Зачастую не в лучшую сторону.
Читая условия и правила использования, стал напрягаться еще больше. Программа выполнена в формате PWA (progressive web app), т. е. без интернета проезд уже не оплатить. Ладно, это понятно, норм. После удаления браузера из системы или очистки его данных (бывает нужно на некоторых сайтах), данные приложения тоже будут удалены. Уже неприятно. Вход осуществляется на выбор из трех вариантов: Яндекс, Google и VK. Уже неплохо, в старом приложении вариантов не было — только Google. Карта привязывается просто, но не совсем понятно где хранятся данные о ней, это неприятно. Написано, что хранение производится на серверах Сбера, но звучит как-то неубедительно что ли. А вот дальше началось полное безобразие.
Внешний вид очень аскетичен, на мой взгляд. Очень.

Ну ок, возможно, просто непривычно. А дальше нормально будет. Идем дальше:

Меню достаточно большое. А если бы у меня экран был поменьше, что тогда? И я почти получил ответ на этот вопрос, но чуть позже.

Настроек немного. Да, в принципе, что настраивать-то? Камерой я обычно не пользуюсь, предпочитаю ручной ввод, поэтому отключаю. Остальные пункты не совсем понятны, оставляю как есть. Попробуем оплатить проезд, нажав соответствующую кнопку:

Оп-па. Клавиатура полностью закрывает поле ввода кода. Я даже не знаю что я ввожу. Явная недоработка! Кажется, я догадываюсь, как отображалось бы меню при меньших размерах экрана смартфона. Ладно, в настройках что-то было про подсказки, попробую отключить:

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

1. Мне не нравится формат приложения.
2. Мне не нравится сайт, на котором нужно привязывать свою карту для оплаты.
3. Мне не нравится внешний вид и то, что он явно «заточен» под большие экраны.
   Проезд оплачивать пока не пробовал и я не вижу никого, кто бы пользовался этим приложением. Наводит на некоторые размышления. Наверное, я пока что подожду немного с его использованием и отвяжу на всякий случай банковскую карту.
   На других маршрутах, кстати, тоже появились QR-коды, но от старых разработчиков. Судя по данным на них, проезд можно оплатить через СБПей или бота в Telegram. С учетом того, что кондукторы отказывались принимать оплату через бота, с этими наклейками тоже лучше подождать. А представляя себе работу чиновников, «нормальной» оплаты проезда, кроме наличных или банковской карты (еще транспортная есть, забыл), в ближайшее время ждать не стоит. Впрочем, думаю, что скоро СМИ отрапортуют, что всё готово, всё прекрасно работает и умолчат о том, что этим приложением никто (или почти никто) не пользуется. Опрос что ли провести? :-)

Мне никогда не нравилось, что в интерфейсе OpenWrt нельзя указать несколько портов при пробросе, можно указать только диапазон. А если мне нужно несколько, объединенных одним сервисом? Например, почта. Если указывать все порты, то получается, что на каждый из них нужно создавать свое правило. В итоге получается такая простыня правил, что ориентироваться в ней становится затруднительно.
По сути, эта заметка — напоминание себе как нужно правильно прокинуть порты во внутреннюю сеть, используя iptables. И, заодно, там же сделаем так, чтобы из локальной сети можно было обращаться к своим серверам по доменному имени.
Идем в раздел Network — Firewall и открываем вкладку Custom rules. Добавляем туда строку такого вида:

iptables -t nat -A zone_wan_prerouting -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j DNAT --to-destination 192.168.1.100

Здесь мы помещает в цепочку zone_wan_prerouting таблицы nat правило, указывающее, что сервисы, обращающиеся из внешней сети на перечисленные порты, должны перенаправляться на сервер с адресом 192.168.1.100. Параметр -р указывает протокол tcp, а параметр -m multiports позволяет указать не один порт, а несколько. Это правило позволит открыть порты для доступна извне, но при обращении к ним из локальной сети придется указывать «прямой» адрес 192.168.1.100. Если вписать свой внешний адрес (IP или DNS), то ничего не выйдет. Чтобы это стало возможным, нужно дописать еще две строки:

iptables -t nat -A zone_lan_prerouting -d 95.170.188.45 -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j DNAT --to-destination 192.168.1.100
iptables -t nat -A zone_lan_postrouting -d 192.168.1.100 -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j MASQUERADE

В первой строке мы говорим, что все обращения к внешнему адресу на указанные порты должны перенаправляться на локальный адрес 192.168.1.100. Во второй строке мы, если так можно выразиться, прячем, что обращаемся из локальной сети.
После нажатия кнопки Save содержимое поля Custom Rules будет сохранено на роутере в файле /etc/firewall.user. Для применения эти необходимо перезапустить файрволл:

/etc/init.d/firewall restart

После этого почта станет доступной из внешней сети и из локальной, причем по доменному имени или внешнему IP-адресу.

Обновление Если оставить последнее правило в таком виде, то исходящий IP-адрес (адрес клиента) будет отображаться как адрес самого роутера в локальной сети: 192.168.1.1. Поэтому следует немного изменить правило, чтобы оно выглядело следующим образом:

iptables -t nat -A zone_lan_postrouting -s 192.168.1.0/24 -d 192.168.1.100 -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j MASQUERADE

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