Системное администрирование *

TL;DR: TeamViewer заблокировал все бесплатные подключения из России в 2022 году. AnyDesk с апреля 2025 года блокируется Роскомнадзором — тысячи жалоб, соединения не устанавливаются или обрываются. Российские аналоги стоят от 72 000 ₽/год и заточены под корпорации. Я сделал Portal — удалённый рабочий стол на WebRTC с прямым P2P-соединением, без серверов-посредников. macOS + Windows. 1 устройство бесплатно. Сайт — portal-app.ru. Telegram — @portalremote.

Что случилось с TeamViewer

5 мая 2022 года TeamViewer объявил о полном прекращении работы в России и Беларуси. Компания:

Заблокировала все бесплатные (нелицензионные) подключения из России и в Россию

Прекратила продажу новых лицензий

Отказалась продлевать существующие контракты

Если вы сейчас скачаете TeamViewer и попробуете подключиться — получите «Невозможно подключиться к партнёру». Всё. Без вариантов. Двадцать лет люди привыкали к этому инструменту, а потом в один день он просто перестал работать.

За последние пару лет в интернете скопилось много статей на данную тему, так зачем же еще одна? Лично для меня была проблема в том, чтобы найти всю информацию по базовой настройке сервера (обновление, защита и т.д.) и в дополнение к этому быстрый способ настройки VLESS в одной статье. Обычно я натыкался на статьи, где есть настройка панели 3X-UI (и то, как я понял, читая комментарии под такими статьями, не всегда правильная) без базовой настройки самого VPS, либо статьи, где всё написано слишком детально, а «много букав» читать, да ещё в последствии воспроизводить самому многим лениво в наше время.

Поэтому в данной инструкции я решил собрать в одном месте и базовую настройку сервера (которую может сделать практически любой, не слишком мудря с настройками), так и настройку Xray без панели 3X-UI всего за пару скриптов.

Всем привет! Мы уже все понимаем, что блокировка Telegram будет в этом году. Сейчас власти делает это этапами, чтобы люди понемногу и без кипиша, мигрировали на Max. Понятно, что не все смогут или захотят это, но тут либо VPN либо более гуманная альтернатива - MTProxy.

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

Всем привет! С вами Сергей Ковалёв, менеджер выделенных серверов в Selectel. В этом дайджесте я собрал подробности самых нашумевших железных новинок за январь — от GPU до новых дисков и сетевого оборудования. Подробности под катом!

Не все инсталляторы linux могут установить систему на btrfs subvolume. Ни один инсталлятор не может установить систему с применением nocow и compress только для определенных subvolume.

На примере Astra linux 1.8.4 с максимальным уровнем защищенности (включен МКЦ и МРД) и написанных мною скриптов для автоматизации я покажу, как перенести установленную систему на btrfs subvolume, а также установить nocow только у необходимых subvolume. Дополнительно будет описан второй скрипт для создания и восстановления снимков.

Fail2Ban долго был про «поставил и забыл», но сейчас он всё чаще работает как сигнализация, которая орёт уже после того, как дверь подёргали десятки раз — и каждый рывок остаётся в логах. Мы перевели сервер управления Netbird с Fail2Ban на CrowdSec и собрали это в практический разбор: как читать JSON-логи Caddy без плясок с регулярками, как вешать блокировки на nftables, и почему community threat intel позволяет отрезать часть сканеров ещё до того, как они успевают что-то «прощупать». По ходу рассмотрим конфиги, команды и наблюдения, что именно меняется в шуме, банах и нагрузке.

В сетевых метриках VDS/VPS легко запутаться, потому что каких их только нет. В статье разберу ключевые, расскажу, как их читать, и посоветую 10 лучших утилит для мониторинга сети. 

Привет, Хабр!

Telegram блокируют всё активнее. VPN детектят и режут. Обычные прокси живут неделю. Что делать? Ответ MTProto Proxy с Fake TLS: специализированный прокси, который маскируется под обычный HTTPS-трафик к легитимным сайтам вроде 1c или sberbank. Для DPI это выглядит как обычный визит на сайт, а на деле стабильный Telegram.

Сегодня разберём полную инструкцию: от выбора правильного VPS до эффективной маскировки и мониторинга.

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

Привет постоянным и не очень читателям :)

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

Ремарка! Я не против конкретных цифр и конфигураций — я против попытки выдать их за универсальный рецепт. Так что этот подход оставим для SEO-статей.

В этом же лонгриде я затрону ошибки мышления при подборе серверов на 5+ лет и сдвиги, которые произошли за последние годы (и особенно хочу поговорить про огромное влияние CXL). Я плотно работаю в этой индустрии больше 6 лет и прошел подобный цикл на практике, да и админы-старожилы рассказали много интересного о том, что было раньше.

Присаживаемся, ложимся или в какой там позе вы читаете — и начинаем.

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

В мире информационных технологий нет ничего постоянного. Стандарты меняются: если раньше стандартом было развертывание локальных серверов и отдельных учетных записей, то сейчас фокус сместился в сторону централизованного управления идентификацией. Современным базовым стандартом для любой развитой IT-инфраструктуры стал Единый Вход или SSO (Single Sign-On).

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

Наша команда на практике прошла путь интеграции с различными SSO. Мы работали с такими решениями, как WSO2 и ADFS, и каждый раз убеждались в том, насколько SSO важен для инфраструктуры.

Этот опыт позволил определить требования к Identity Provider’у: открытость, масштабируемость и возможность адаптации под быстро меняющиеся бизнес-задачи. И здесь на первый план выходит Keycloak.

Почему именно Keycloak?

В отличие от многих аналогов, Keycloak — это решение с рядом преимуществ:

Ранее мной уже был опубликован цикл статей по теме SD-WAN. В некоторых статьях раскрывались детали работы решения Kaspersky SD-WAN. Делюсь, если интересно: первая, вторая, третья.

Новая статья – их продолжение. В конце 2025 года был выпущен новый релиз продукта Касперский SD-WAN версия 2.5, в который были внесены существенные изменения в функционал, обеспечивающий стабильность связи. Здесь детально разберу механизмы балансировки в режиме нестабильности связи и способы борьбы с такими проблемами в версии 2.5.

Записки системного администратора о поиске маленьких ошибок приводящих к большим проблемам. Делюсь опытом поиска плавающих проблем в различном ПО и способом их решения.

Я много лет мечтал построить свою облачную платформу — и если раньше я пытался реализовать эту мечту в рамках нескольких компаний и проектов, то в последние годы я запустил собственный проект, Cozystack. В своей статье я расскажу о нашем опыте и о том, как, на мой взгляд, стоит подходить к созданию современной инфраструктурной платформы, в основе которой — Kubernetes и Kubernetes API.

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

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

Разбор конфигураций, Java-параметров и логов — путь рабочий, но не всегда оправданный по времени.

SD‑WAN — это не «еще один VPN», а надстройка, которая управляет вашими каналами связи как единой системой: сама выбирает маршрут, проверяет качество каналов и подстраивается под бизнес-требования к доступности и безопасности.

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

Здравствуйте! Меня зовут Юрий Юшкевич, я руководитель ИТ-разработки и в последние годы отвечаю за команду, которая развивает и поддерживает нашу внутреннюю платформу оркестрации бизнес процессов на базе Camunda 7. Как и многие, кто использует Camunda 7 в качестве движка для автоматизации процессов, в начале этого года я столкнулся с интересной дилеммой: Camunda 7 прекращает развитие, а Camunda 8 вызывает много вопросов.

Привет, мир! Недавно я решил пополнить свои знания протоколов NTLM'ом; и, к большому сожалению, стоящих материалов, которые бы подробно и полно описывали работу NTLM, я не нашел (есть лишь пара годных статей на английском языке, но и они, на мой взгляд, не дают нужного уровня глубины). Потому я решил написать статью, которая бы в подробностях рассказала о том, как работает данный протокол и удовлетворила даже самого душного нерда, каким автор и является :-)

Что такое «стратегия ИБ», которую поймёт Бизнес

Компания среднего размера. Один системный администратор отвечает за всё. Владелец не спрашивает о стратегии. Администратор действует по интуиции.

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

Владелец платит. Потому что недельный бэкап означает неделю простоя.

Пока ИБ-директор говорит о технических угрозах правление не видит бизнес-ценности. Когда он говорит о рисках — слышит деньги.

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

Легче купить инструмент который обещает обнаружить атаку после того как она произошла. Он не требует изменений. Не требует признаний. Так создаётся видимость управления.

Если система не падает никто не видит как специалист её защищает. Так возникает скрытая обратная мотивация не слишком усердствовать с профилактикой чтобы оставаться востребованным в момент кризиса.

Прошло уже достаточно много времени с того момента, когда случилась изоляция России от мирового рынка IT. Нам пророчили кромешную тьму: что все технологии для нас будут изолированы, что мы откатимся назад в 90-е, у нас будут только калькуляторы (а может даже и их не будет), а мы потихоньку будем доставать счёты. И первое время действительно была паника, хаос, все бегали и не понимали, что делать. Насколько я помню, даже из-за проблем с логистикой огромное количество купленных заказов было просто остановлено на границах европейских стран – и так не приехало к нам.

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