Некоторые мысли по поводу организации DNS-трафика в сетях с Mikrotik

Последние нововведения буквально уже прямым текстом говорят, что незащищенный DNS-трафик становится небезопасен и может потенциально принести множество проблем на ровном месте.

Сегодня мы рассмотрим один из возможных вариантов в сетях с использованием в качестве шлюза роутеров Mikrotik.

Ой, да что там думать, скажет иной читатель, включаем DoH и понеслась! Но не все так просто. При включении DoH перестают работать записи типа FWD, что во многих случаях неприемлемо, поэтому нужно искать другое решение.

Завернуть DNS-запросы в трубу… Ну такое себе решение, скажем честно. Труба в наше время может отвалиться в любой момент, и тогда вся ваша сеть вообще окажется без DNS.

Поэтому работать надо через основное подключение, но исключительно по защищенным протоколам.

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

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

Для разрешения запросов мы подняли дополнительный кеширующий DNS-сервер Unbound, но вы можете использовать любое иное решение, главное, чтобы оно умело использовать в качестве апстрима сервера DoT/DoH.

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

Почему DoT, а не DoH? DoT проще в настройке и позволяет четко определять такой трафик, что полезно если вы используете сложные правила фильтрации. С другой стороны, это делает видимым такой трафик для провайдера, но доступа к нему он все равно не имеет.

Смысла прятать факт наличия DNS-трафика в зашифрованном виде особо нет, но если вы хотите скрыть такую активность, то лучше использовать DoH. В общем – на ваш выбор.

После чего в качестве используемого DNS-сервера для Mikrotik указываем адрес нашего Unbound. Для клиентов сети основным DNS как был Mikrotik, так и остался, это нужно для того, чтобы работали FWD записи и разные другие правила.

Этот режим показан на диаграмме зелеными стрелочками. DNS-запрос приходит на Mikrotik и если его не нужно перенаправлять на какой-либо специфический сервер, то он уходит на Unbound, а с него по DoT/DoH на выбранный вышестоящий DNS-сервер.

А что будет, если клиент явно укажет на своем устройстве другие DNS-сервера? Все просто, решаем при помощи правила на Mikrotik:

/ip firewall nat
add action=dst-nat chain=dstnat comment="SAFE DNS" dst-address=!192.168.1.0/24 dst-port=53 protocol=udp to-addresses=192.168.1.53

Где 192.168.1.0/24 – адрес вашей внутренней сети, а 192.168.1.53 – адрес сервера Unbound.

После чего ваш роутер будет перехватывать все транзитные DNS-запросы и отправлять их на ваш Unbound-сервер. Этот режим показан на схеме голубыми стрелочками.

Также для контроля возможной утечки DNS советуем вам на первых порах добавить в брандмауэр, на самый верх, еще два правила:

/ip firewall filter
add action=passthrough chain=output dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp
add action=passthrough chain=forward dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp

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

Сразу дадим одну наколку, если у вас используются коммутируемые подключения или вы получаете настройки по DHCP – обязательно снимите галочку Use Peer DNS.

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

А можно мы сами?

- А у нас тут 1С не запускается, пишет недостаточно места…

- Значит недостаточно места, надо почистить.

- А если вы подключитесь, то возьмете как за час работы?

- Да, это минимальная такса.

- Но там же просто место почистить.

- Да какая разница, мы тратим свое время. Время – деньги.

- А можно мы сами почистим?

- Можно.

На следующий день сообщают, что они почистили, место есть, но теперь 1С вообще не запускается. 😫

Наверное, вы уже догадались, они удалили самую большую папку в корне диска, с простым и понятным названием «СТ», в которой была база 1С. 🤦‍♀️

Сэкономили денег, однако.

Последний бекап от марта месяца. Но документов немного, дня за два-три в пару рук внесут все обратно.

Морали не будет. Каждый сам определяет, что дорого, а что нет. И несет последствия своего выбора.

Не спеши, а то успеешь

В начале нашей заметки я расскажу одну поучительную историю. В студенческие годы физрук подрядил нас почистить от снега спортплощадку. Срок – пара. Ну мы минут за 30 справились, пришли к нему гордые и довольные.

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

Любые нормы на чем-то да основаны, проверены временем и т.д. и т.п. Сказали чистить снег пару – значит пару. Это сегодня снега пару сантиметров выпало, и вы за полчаса справились, а завтра его по колено наметет? А норма – штука такая, если ее регулярно перевыполнять, то ее обязательно поднимут (или сократят) и легче никому от этого не станет.

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

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

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

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

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

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

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

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

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

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

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

Любую норму или план можно перевыполнить только один раз, в этом случае вас похвалят и дадут конфетку, второй раз вас просто одобрительно похлопают по плечу, а на третий сделают замечание, что плохо работаете, недорабатываете.

Для себя я давно вывел некоторые эмпирические коэффициенты, любые материалы на проекте умножаем на 1,25, а время просто увеличиваем в полтора, а то и два раза. Запас карман не тянет, особенно если это такой ресурс, как время.

Новый формат DEB822 для источников APT

Так уж пошло, что многие привычные вещи воспринимаются нами чем-то незыблемым, а попытка нарушить текущий ход вещей часто воспринимается в штыки. Новый формат источников APT - DEB822 не исключение, он появился начиная с выпуска Debian 13, а пользователи Ubuntu познакомились с ним немного раньше, начиная с Ubuntu 24.04. В данной статье мы подробно разберем новый формат, его основные отличия и преимущества перед привычным старым.

Заметка на эту тему уже была, теперь полноценная статья, которую мы достали из черновиков, вычитали, причесали и опубликовали.

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

✅ Читать: https://interface31.ru/post/novyj-format-deb822-dlya-istochnikov-apt/

Их нравы
 
На конференции Linux App Summit Себастьян Вик (Sebastian Wick), мэйнтейнер инструментария Flatpak, и Адриан Вовк (Adrian Vovk), создатель инсталлятора для GNOME OS и один из разработчиков systemd-homed и systemd-sysupdate, выступили с докладом о будущем системы самодостаточных пакетов Flatpak.
 
В докладе упоминалось намерение создать для нужд Flatpak новый процесс systemd-appd для управления правами приложений и вложенной изоляции. Важный нюанс: код ещё не написан, а поддержка пока только задумывалась.
 
Но тут «разверзлись хляби небесные» в социальной сети Fediverse началась волна агрессии. Разработчиков обвинили в «насаждении диктатуры», «предательстве портативности» и «союзничестве с Ландьюком». Критика сыпалась на этапе концепции, без анализа доклада. Аргументы «мы ещё даже код не написали» игнорировались.
 

Брайан Ландьюк (Bryan Lunduke) — известный технический блогер, яростный критик systemd и корпоративного влияния в Linux . В данном контексте обвинение в «союзничестве» с ним используется как токсичный ярлык и обвинение в намеренном вреде проекту ради идеологии.  

 
В результате Адриан Вовк заявил, что до начала этой токсичной кампании он искренне хотел найти элегантное решение для пользователей альтернативных init-систем (например, выделить appd в отдельный демон, как это сделали с elogind). Но после потока неконструктивной агрессии и обвинений у него пропала мотивация тратить личное время и силы на это:
 

Но, честно говоря, всё это обсуждение сейчас совершенно бессмысленно, пока мы не написали ни единой строчки кода. Если быть откровенным, до этой травли в Феди я планировал максимально тактично отнестись к сценарию использования без systemd. Но тут я увидел, как кто-то в открытую обвиняет нас в том, что мы «союзники Ландьюка».

Так что, извините, но у меня больше нет ни малейшего желания тратить своё время на это дерьмо. Оно того не стоит.

 
К чему это привело? Да к тому, что systemd теперь станет обязательной зависимостью Flatpak, альтернативные решения разработчики больше рассматривать не желают.
 
И это не первый случай токсичного поведения меньшинств, которые потом искренне удивляются почему никто не хочет поддерживать их решения и вообще тратить на них время. Многие начинают склоняться к теориям заговора и козням корпораций.
 
На самом деле проблема не в systemd vs openrc (или подставьте сюда все что хотите). Проблема в культуре дискуссии. Токсичное меньшинство, кричащее громче всех, создаёт иллюзию «общественного мнения». Но реальные мейнтейнеры видят: за громкими лозунгами стоит оголтелый фанатизм и догматическое отторжение инакомыслия.

Настраиваем Visual Studio Code для удаленной работы через SSH

Сегодня все чаще и чаще для конфигурационных файлов используются продвинутые текстовые форматы, такие как JSON или XML, имеющие строгий синтаксис и структуру.

Их применение облегчает программную обработку данных, но при этом они все еще остаются легко читаемыми человеком.

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

Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.

✅ Читать далее: https://interface31.ru/post/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh/

Обновление PostgreSQL в Docker через pg_dumpall
 
Обновление PostgreSQL между мажорными версиями задача не самая простая, недостаточно просто загрузить новый контейнер, нужно еще выполнить конвертацию структуры кластера СУБД, которая меняется от версии к версии.
 
Для небольших и средних баз идеально использовать импорт/экспорт при помощи утилиты pg_dumpall, что полностью исключает риск повреждения исходных данных, плюс у вас на руках всегда остается актуальная резервная копия в виде дампа всего кластера.
 
Итак, приступим, допустим мы изначально имеем:
 

services:
  db:
    container_name: postgres-db

 
В нашем случае:

▫️ db — имя сервиса Compose
▫️ postgres-db — реальное имя контейнера Docker
 
1️⃣ Остановим весь стек и запустим обратно только контейнер с СУБД, это исключит возможную запись в БД во время выгрузки:
 

docker compose stop
docker compose up -d db

 
Теперь выполним выгрузку дампа всего кластера:
 

docker exec -t postgres-db pg_dumpall -U postgres > full_backup.sql

Проверяем, что файл выгрузки создан. После чего останавливаем контейнер с БД:
 

docker compose down

 
2️⃣ Следующие шаги будут несколько различаться в отличие от того, используем ли мы Named Volumes или Bind mount, но в любом случае наша задача запустить новый контейнер СУБД с пустым томом.

🔹 Для Named Volumes было:
 

services:
  db:
    image: postgres:17
    volumes:
      - pg_data:/var/lib/postgresql/data
volumes:
  pg_data:

 
Стало:
 

services:
  db:
    image: postgres:18
    volumes:
      - pg_data_18:/var/lib/postgresql/data
volumes:
  pg_data_18:

 
🔹 Для Bind mount было:
 

services:
  db:
    image: postgres:17
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Стало:
 

services:
  db:
    image: postgres:18
    volumes:
      - ./postgres-data-18:/var/lib/postgresql/data

 
3️⃣ Запускаем СУБД:
 

docker compose up -d db

 
Мы нее запускаем весь стек, чтобы раньше времени приложения не начали писать в новую чистую БД.
 
Ждем пока база инициализируется и готова будет принимать соединения, для этого выполним команду:
 

docker logs -f postgres-db

 
Как только появится сообщение:
 

database system is ready to accept connections

 
Можно двигаться дальше. Загружаем дамп кластера СУБД:
 

docker exec -i postgres-db psql -U postgres < full_backup.sql

 
Теперь запускаем весь стек:
 

docker compose up -d

 
4️⃣ После чего рекомендуется выполнить оптимизацию загруженной базы:
 

docker exec -it postgres-db vacuumdb -U postgres --all --analyze-only

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