​​Про IPsec для самых маленьких

Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).

Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.

При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.

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

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

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

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

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

В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией.

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

Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.

Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.

GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.

Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.

А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.

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

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

Устанавливаем и настраиваем Aspia - бесплатную программу для удаленного управления ПК

Рано или поздно системные администраторы задумываются о собственном решении для удаленного управления ПК. Это может быть связано с уходом с российского рынка привычных продуктов, финансовыми вопросами или соображениями безопасности.

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

Сегодня мы рассмотрим как установить и настроить на собственном сервере Aspia - бесплатный комплекс программ для организации собственной инфраструктуры удаленного управления ПК.

Плюсы:

▫️ Легкая установка и настройка, на клиент можно передать набор с уже готовыми настройками.

▫️Адресные книги. Книг можно наделать множество, для разных пользователей с разными правами.

▫️ Стабильная работа, даже на плохих каналах.

▫️ Много разных сервисных возможностей. В т.ч. запись видео без подтверждения с той стороны.

Минусы:

🔸 Сборка серверной части под устаревшие дистрибутивы

🔸 Клиентская часть только для Windows

🔸 Нет мобильного приложения.

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

https://interface31.ru/tech_it/2024/09/ustanavlivaem-i-nastraivaem-aspia-besplatnuyu-programmu-dlya-udalennogo-upravleniya-pk.html

one.one.one.one вышел на тропу войны

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

Проверил у себя - работает. Стали разбираться и выяснили, популярный DNS-сервер от Cloudflare не разрешает домены налоговой (а может и еще кого, не проверял).

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

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

🎯 Как подготовиться к собеседованию, чтобы вас запомнили как сильного кандидата? Даю пошаговую инструкцию в своем телеграм канале.

Подписывайтесь.

erid: 2W5zFGuX5YU

Cloudflare упал, а вместе с ним половина интернета, включая как крупные ресурсы, так и множество мелких.

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

До этого не столь давно наблюдались не менее масштабные проблемы из-за падения Amazon AWS.

Кстати, что показательно, вместе с Cloudflare упал и сайт отслеживания сбоев Downdetector.com 😁

​​WireGuard и systemd-resolved

Сегодня столкнулись с еще одной трудно диагностируемой ситуацией. Дано – WireGuard клиент на Debian в филиале, соединяется с WireGuard сервером на Ubuntu в основном офисе.

Коллега попытался перенаправить DNS-запросы на сервер основного офиса, указав в конфиге клиента опцию:

DNS = 192.168.10.53

Которая указывала на DNS-сервер офиса. И вроде бы даже все получилось. Но очень быстро выяснилось, что сломалось разрешение имен на самом сервере.

На любую попытку что-то пропинговать система сообщала:

Временный сбой в разрешении имен

Достаточно быстро выяснилось, что разрешение имен ломается только если поднят WireGuard-интерфейс.

Далее последовали попытки разобраться в ситуации, но безуспешные. За разрешение имен в современных системах отвечает служба systemd-resolved, которая поднимает на 127.0.0.1 локальный кеширующий DNS и направляет все запросы приложений на него.

Реальные же запросы systemd-resolved обрабатывает согласно внутренним правилам, в зависимости от настроек службы и запрашиваемых имен.

Решение гибкое, универсальное, удобное. Но после старта WG-интерфейса служба полностью переставала работать.

Анализ показал, что если в настройках интерфейса WireGuard указана опция DNS, то адрес добавлялся в файл настроек systemd-resolved, причем добавлялся корректно.

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

Как только мы убирали из конфига WireGuard опцию DNS и перезапускали службу - systemd-resolved тут же оживал, без всяких перезапусков или иных действий с ним.

Беглый поиск по интернету показал, что проблема не нова и известна. Скорее всего это баг, только вот чей.

Поэтому не используйте опцию DNS в настройках WireGuard интерфейса на системах с systemd-resolved, либо отказывайтесь от использования последнего.

Недельный буткемп по Linux 📌

Ждем всех, кто хочет на 7 дней погрузиться в профессию администратора Linux. Мы совместно пройдем полный путь от нуля до развёртывания рабочего веб-сервера.

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

Когда видите строку chmod 755 script.sh, вы:

🧩 Понимаете, что это фильм для взрослых, и переключаетесь на что-то другое.
🧩 Догадываетесь, что это про права, обязанности и привилегии.
🧩 Мысленно видите дискреционную матрицу rwxr-xr-x.

➡️ Всего 10 быстрых вопросов ждут вас в боте-помощнике. Там же будет информация про то, как попасть в буткемп. Не упускайте возможность!

Подборка наших статей про BIND, ISC DHCP и Kea

▫️ Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP

▫️ Настраиваем отказоустойчивый DNS-сервер на базе BIND 9

▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP

▫️ Установка и базовая настройка DHCP-сервера Kea

▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP

​​Проверяем DNS-записи

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

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

Я думаю, что все знают утилиту nslookup и часто ее используют, но не все умеют пользоваться ей на все 100%. Данная утилита есть и в Windows, и в Linux, при этом синтаксис ее полностью идентичен для обоих систем.

Чаще всего она используется для получения A-записи:

nslookup ya.ru

А если нам нужно проверить другие записи? Нет ничего сложного, используем дополнительный ключ -type:

nslookup -type=ns ya.ru

В этом случае мы получим список серверов имен (NS-серверов), обслуживающих данный домен. А если, скажем, надо узнать список MX-серверов, принимающих почту, то выполним:

nslookup -type=mx ya.ru

Для проверки обратной PTR-записи укажите интересующий IP-адрес, при этом используйте обычный формат:

nslookup -type=ptr 203.0.113.1

Утилита сама преобразует его в:

1.113.0.203.in-addr.arpa.

Еще одна важная задача – получить результат от конкретного сервера, особенно если есть подозрения что текущий сервер возвращает неверные или устаревшие записи. В этом случае просто укажите адрес нужного DNS-сервера в самом конце команды:

nslookup -type=mx ya.ru 8.8.8.8

В этом случае утилита проигнорирует системные настройки DNS и выполнит запрос на указанном сервере.

Рейтинг IT-брендов работодателей — 2025. Ключевые тренды рынка от ЭКОПСИ и Хабр.

Завершено шестое масштабное исследование рейтинга IT-брендов работодателей. В основе — аналитика предпочтений более 30 000 IT-специалистов, которые оценили 127 ведущих компаний (из почти 700 в исследовании) по 41 метрике.

Ключевые инсайты 2025 года:

✅ IT-рынок переходит от роста к оптимизации. Если в 2024-м были рекордные бюджеты и новые игроки, то сейчас их почти нет, а конкуренция резко обострилась.

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

Кому и зачем нужен этот рейтинг?
◾️ IT-специалистам, которые в поиске или задумываются о развитии. Поможет найти компанию, чьи ценности и условия совпадают с вашими ожиданиями.

◾️ Руководителям и HR-командам IT-компаний.
Покажет сильные и слабые стороны бренда работодателя.

◾️ Всем, кто связан с IT-рынком:
Для инвесторов, аналитиков, журналистов — это точный срез текущей ситуации.

💡 Смотрите результаты исследования 2025, изучайте и сравнивайте динамику.

#реклама
О рекламодателе

Включаем отображение Samba-сервера в сетевом окружении Windows

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

Это связано с полным отказом в Windows от использования протокола SMB1 и невозможностью обнаружить Samba по протоколу NetBIOS. Современные Windows системы используют для обнаружения устройств WSD (Web Services for Devices) и сегодня мы расскажем, как добавить его поддержку для вашего сервера Samba.

https://interface31.ru/tech_it/2023/07/vklyuchaem-otobrazhenie-samba-servera-v-setevom-okruzhenii-windows.html

Статья актуализирована и дополнена

🎥 Вебинар по Linux: Настройка Nginx/Angie для высоких нагрузок и защиты от DoS-атак

👉 На вебинаре вы узнаете:
-Как оптимизировать конфигурацию Nginx/Angie под высоконагруженные проекты.
-Какие модули и параметры отвечают за производительность и отказоустойчивость.
-Как реализовать базовую защиту от DoS-атак средствами веб-сервера.
-Как мониторить и анализировать поведение сервера под нагрузкой.

💪 В результате вебинара вы:
- Научитесь настраивать Nginx/Angie для стабильной работы под высокой нагрузкой.
- Сможете применять встроенные механизмы ограничения запросов и защиты от DoS.
- Освоите подходы к балансировке и кешированию трафика.
- Получите практические рекомендации по тестированию производительности и мониторингу.

🎁 Все участники вебинара получат специальные условия на полное обучение курса "Инфраструктура высоконагруженных систем"

👉 Для участия зарегистрируйтесь: https://otus.pw/wg7M/

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Keenetic принудительно обновил прошивки роутеров

В начале ноября Keenetic выпустил бюллетень безопасности KEN-PSA-2025-WP01, посвященный уязвимости типа CWE-521 (слабые требования к паролям), данная уязвимость получила уровень 8,8 балла по шкале CVSS и затрагивала все устройства под управлением KeeneticOS ниже 4.3.

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

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

Также были отмечены массовые случаи взломов роутеров Keenetic автоматическими сканерами, которые использовали типовые пары логин:пароль.

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

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

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

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

Тот же сбор данных, проникновение во внутренние сети и т.д. и т.п. Особенно учитывая популярность устройств данного бренда и их широкое использование в организациях, в т.ч. и государственных.

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

Прецедент заставляет крепко задуматься и еще раз пересмотреть свое отношение к данному классу оборудования и связанных с ними рискам.