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

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

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

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

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

2. Использование имени вместо адреса в шлюзе. Оно и так работает, конечно, но в этом место в случае реконнекта или изменений можно найти приключений, маршруты просто перестанут работать.

С связи с расширением сети на даче появилась задача как-то группировать абонентов и что-то такое с ними вытворять — вводить ограничения и проводить мониторинг. Скорость и стабильность работы в связи со сменой оборудования и мобильного оператора возросла, но для спокойной жизни этого недостаточно. В задаче исходим из того, что у нас есть центральный маршрутизатор, в который сходятся несколько точек доступа. Сами точки доступа только передают подключение сразу в маршрутизатор без каких-либо затей. Если на 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 с определенными условиями и ограничениями, оттуда вручную мы его можем перенести в другую «группу» или сеть с другими условиями, с более мягкими или жесткими ограничениями. Достаточно удобно, если не считать ручную работу.

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

В далеком 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. и конечно стабильная работа, высокий аптайм как всегда.

Некоторое время выбирали регистратор в машину. Совсем дорогую модель больше десяти тысяч брать совсем не хотелось, не оправданно как-то. Плюс душит традиционная экономия. Не мудрствуя лукаво, остановились на Neoline WIDE S55. Средний ценовой диапазон, неплохая начинка внутри, достаточно новая модель, сравнительно компактные размеры, неплохие отзывы, простое меню и возможность обновления.

Характеристики:
• Разрешение видео: Super HD 2304*1296 (30 к/с)
Full HD 1920*1080 (45 к/c)
HDR Full HD 1920*1080 (30 к/c)
• Угол обзора: 150° (по диагонали)
• Дисплей: 2,7 дюйма
• Видеозапись (битрейт): MOV/H.264, WDR
• Встроенный аккумулятор (мА·ч): 180
• Поддержка карт памяти: MicroSD 8Гб — 64Гб (Class 10)
• Интервал циклической записи, мин: 1/3/5
• Встроенный GPS: да
• Встроенный микрофон/динамик: да
• Штамп дата/время: да
• Штамп гос.номера: да
• Штамп геолокации: да
• G-sensor: да
• Датчик движения: да
• Режим парковки: да
• Непрерывная запись: да
• Автовключение: да
• Температурный режим, С°: эксплуатация: -10/+60; хранение: -20/+70;
• Входное напряжение ЗУ: DC 12/24В
• Входное напряжение прибора: DC 5В/1A
• Кронштейн, тип: присоска
• Размеры: 89 x 53 x 28.5мм
• Вес: 86 гр

И все вроде в нем неплохо, в целом впечатления приятные. Небольшие мелочи портят общую картину:

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

Вспоминаю с ностальгией вот такие записки пользователей на рабочем столе:

Стоило пополнить баланс и автоматом подключилась платная услуга. С чего бы вдруг? Отключили в личном кабинете, но осадочек остался. Так бессовесно деньги со счета снимать совсем некрасиво.

Вопрос к Мегафону остался без ответа:

Мандзи, знаменитый воин-самурай, когда-то отнял великое множество жизней, в том числе и невинных, и теперь на нём лежит проклятие бессмертия. Есть только один способ избавиться от проклятия — убить 1000 злодеев. Однажды к уединённой хижине Мандзи приходит Рин, девушка, чьи родители были жестоко убиты. Рин известно, кто виновен в убийстве её семьи, и она просит самурая помочь ей отомстить. Эта благородная миссия не только даст Мандзи шанс основательно приблизиться к заветному числу убитых злодеев, но и изменит его жизнь сильнее, чем он мог представить. (Экранизация популярной манги Хироаки Самуры. 100-я режиссёрская работа Такаси Миикэ.)

Самая большая беда фильма — это экранизация. Почти всегда «впихнуть невпихуемое» не так просто, а в итоге получается обычно хуже чем оригинал (в частности манга или даже аниме). Произведение похоже на цельное, но местами кое-где провисает. Если не знакомы с тем, по чему экранизация, для составления мнения вполне можно посмотреть.